Far McKon

Creating Software, Hardware, and Community

Archive for category Professional

New gig at Bulogics

Mar 23

Posted by FarMcKon in Personal, Professional | 2 Comments

Most of my friends know I left MakerBot back in December/January. They were going in a direction that didn’t fit my style/interests and the commute back and forth to NYC was becoming a real headache, especially with a little human in my life. Someday when dust has settled I’ll talk about it. But for now there is too much chance my opinion would misunderstood or ‘creatively’ misinterpreted by folks that have been with MakerBot. No hard feeling on my end, but the situation just wasn’t working out.

After leaving I took some time off, then spent some time taking took a look around the Philadelphia scene for any interesting opportunities. After talking to several shops I finally found a great fit for my interests and skill.

As of last week I’ve joined on with BuLogics as Chief Innovator. I’ll be once again herding nerds and working to keep the engineering and design team in close coordination with the business folks. Two things I enjoy, and am pretty damn good at.

Part of what set BuLogics offer apart was a chance to have a big influence in their next stage of growth. They are looking to expand and focus their skills a bit more cleanly. It’s hard to pass up such a great opportunity there to help take an organization to the next stage of growth.

Another great side effect of the new position is that I have a lot more flexibility to blog. So you all can look forward to more posts about teams, teamwork, and creating a culture of making both here and over at BuLogics blog.

P.S. also, check out the terrible bio photo :( It’s the only one I had available when they posted that I’ll have to change that soon.

Tags: , , ,

mea maxima culpa

Feb 18

Posted by FarMcKon in Personal, Political, Professional | No Comments

It is sometimes hard to keep to a charter or agreement one has made without public acknowledgement and feedback.  People are social animals, and we are well built to follow social contracts, but sometime private agreements are forgotten.

So it’s with a sadface :( that I write this post to publicly admit I failed to stand by the ‘Not to Speak or chair all male panels’ pledge I signed on for.  To be fair, the panel was chaired by a woman (the fantastic Phoenix Wang) and it wasn’t a public event.   But nonetheless,  I took a pledge and dropped the ball. Mea Maxima Culpa.  It was a pledge I signed without talking much about, and I completely forgot I agreed to the pledge until the day after the panel. Interestingly enough, I just took a look back at the pledge page, and I can’t read the pledger to see who else may be slipping up, or defecting. Nor did I see any suggestions on how to make up for a slip-up for pledges that forgot their pledge, or who get stuck in a rock/hard-place and must take a panel without a woman member for some extra-ordinary reason.

If anyone has any good suggestions for a proper Mea Culpa for people that don’t live up the the pledge, drop ‘em in the comments. I’ll be picking one of them, or inventing my own, to make up for failing at that pledge.

Tags:

Hofstede’s cultural dimensions and Developers

Feb 4

Posted by FarMcKon in Professional | 2 Comments

Back in the 1960′s and ’70′s a researcher for IBM named Greet Hofstede did some amazing research about culture, and found 7 cultural dimensions that map onto all human cultures, and knowing those dimensions tell a lot about how the culture behaves. Those dimensions are:

  • power distance (PDI)
  • individualism (IDV)
  • uncertainty avoidance (UAI)
  • masculinity (MAS)
  • long term orientation (LTO)

I’ve also gotten into a habit of thinking about how colleges fit into that scale, so I can better understand what they want or expect from a working (or personal) relationship. It’s an interesting and useful lens to use when figuring out how to work with people in an organization that you don’t automatically click with.

So Long, and thanks for all the fish!

Feb 1

Posted by FarMcKon in Personal, Professional | 2 Comments

This week was my last week with MakerBot.

Two-ish year ago phooky asked me to interview as a lead desktop developer.  I wasn’t really looking for a job, but since I respected him and his incredible hacks, I agreed.  At the time it was a small pre-funding startup. To work with a hacker I respected so much, and on 100% Open Source technology was enough of a draw me from Philadelphia to work in Brooklyn.  Since then I’ve been shuttling back and forth from Philly to Brooklyn most of the week so I could herd the nerds for MakerBot.   It’s been an amazing opportunity, but a recent addition to my family means I need to be in Philly full time.

MakerBot gave me the challenge and honour of building a great department to create a stellar product. I also had the rare joy of a blank slate on which to redesign and implement our new desktop software stack, hand in hand with a group of  brilliant developers.   We created a new slicer, a new tool-chain system, a new device driver, and even a beautiful and simple UI on a tight schedule, with some great partners. Despite the controversy about closing some source access to MakerWare,  it’s a product I am very proud of.  It’s fast, robust.  It ran cleanly on 3 platforms from first day it shipped Without a doubt it is the most impactful product I’ve shipped. The most on-schedule product I’ve shipped too!

It’s quite bitter-sweet to be leaving MarkerBot, and a department I shaped, but c ‘est la vie.  Goodbye Brooklyn, and MakerBot!  It’s been an honour, a challenge, and a joy working with you.   I’ll miss the great humour, the inspired hacks, and the great brainstorming.   Even though you won’t really need it, I wish you all the best of luck.  With the pool of talent still there, I’m sure the company will grow and succeed regardless.  I’ll always look back fondly on the great time and great people I worked with at MakerBot,  and Ilook forward to seeing great products and projects you ship in the years to come.

… but at the same time, Hello Philadelpha!  It’s good to be back full time.  Lets get into some trouble.

Tags: , ,

What we believe about software development

Jan 23

Posted by FarMcKon in Code, Design, Professional | No Comments

I came across an excellent (and old) online talk by Greg Wilson on the net today, covering what we believe about software development. It’s a good talk about how little science we use in deciding and reviewing how we plan software, and highlights how many bad or guesstimate numbers computer scientists and engineers throw around when talking about their profession. Watch the video.

The best developers are 28x more effective than the worst

Along with the bad statistics of it, it’s not backed by good data. The studies were long ago with small sample sets, they really don’t apply to modern conditions. Common sense? Not especially. Also, there is the statistical problem of *ever* comparing the best to the worst. It’s a useless measure since ‘worst’ could be someone taught to code an hour ago. Comparing against mean/median/mode is probably a lot smarter.

SCRUM and Sprints keep software from being late

Another good point. As far as I’m concerned, working in a sprint system is what got MakerWare out the door on such a great tight schedule. Iterative design and culling features, as well as allowing for error and error correction during the process. But the plural of anecdotes isn’t data, the plural of anecdotes is rumors. Is there really smarter planning going on? Smarter throwing away features? What is the actual process that makes SCRUM seem or be, better than planning up front?

Until I watched the video, I had not recognized how many software process decisions we as a culture made by anecdote based suggestions, or convinced over beer discussions. If you have time, watch the talk, or add his blog to your RSS reader.

Tags: , , ,

Twelve Leverage Points on a system

Dec 10

Posted by FarMcKon in Professional | No Comments

I was reading up on some software management design, and through the random links of the internet I came across the wikipedia article on Twelve Points of Leverage. Having worked with a lot of system, I’ve always been curious about system, and what drives them.

I was blown away by the fact that someone had the insight (and gall) to totally generalize large system input and control, and pretty succeeded at it. There is a single developer* article on the topic, but I’m quite astounded it doesn’t show up in engineering or Comp Sci more often.

Relicense an open source project?

Nov 20

Posted by FarMcKon in Professional | No Comments

There are a couple of great posts about Re-licenseing VLC (pt1) as an LGPL project (pt2). One of my friends was on the fringes of similar work with Angbnad a while back, and the loops they jump through are amazing (and crazy).

In other news, during an upgrade my site was switched to ‘Don’t let search engines crawl this site’ So hopefully I will be reindexex soon, and searchable.

Tags: ,

When I’m not in vim, I’m in a bug tracker

Nov 8

Posted by FarMcKon in Personal, Professional, Quotes | No Comments

There is a great little post that came up the other day called Be Nice to Programmers. I really get the authors post in a way that kind of disturbs me. In his own words:

When I’m not in vim I’m in the bug-tracker, a list of negatives. A list of what’s broken and needs to be fixed. A list of ways in which I fucked up.

That post is entirely true. The 21st century is full for marvals, and being a prorgammer is one of them. By waving my fingers around for a few hours, I can make all kinds of things happen, nearly instantly, all over the world. However my own day to day thoughts are very programmer-like, and tend to be along the lines of what can be better? What is even slighly broken? What slightly broken things did we ship that *no one knows about because they don’t even use it. I can clearly remember days of getting very upset because one customer (of thousands) posts a bug for a weird set of settings that causes things to, as they say, TOTALLY FAILSAUCE.

To all my fellow programmers out there, take it easy, take 15 minutes a step away from the bug-tracker, and spend an hour today enjoying what you create, instead of finding flaws in it. It may be be the best 15 minutes of you day, or even your week.

Tags: , , ,

Clothesline Principle, and accounting for Open Source value

Oct 12

Posted by FarMcKon in Personal, Professional | No Comments

The Clothesline Principle is this: If you switch to partial solar energy production, you can look at your electricity bill, and say ‘oh, 30% of my electricity comes from solar!’ and feel good, and value that investment in getting off the grid. If you switch to using a clothesline for drying your clothes, you’ll probably not even realize your bill is a bit cheaper, and never account for that free work. This principle hits us in all kinds of ways, my favorite being that education of kids preventing all kinds of later problems with adults. Few counts health-savings from kids properly educated about health as part of health care reform. It’s hard to do.

One place this hits me personally is Open Source. I recently had a conversation with someone about the cost of software development. The question I was asked was “How can your company share thousands of dollars in software development product? That’s throwing money away.” I’ve worked in Open Source long enough, it was a bit hard to go back to first principles, and answer them. But when I did, the first thing I came back to was “First, because we save more than that by using Open Source to start with”.

That got me thinking about the Clothesline Principle. When we (for example) grab an awesome math library that is Open Source and incorporate in into a project, no one asks for how much it costs. There is no department meeting to debate it’s use vs value, and no one in PHB-land even notices. That huge chunk of value we just incorporated is largely left off the balance sheets, and off the radar. That is a mistake.

I’ve encouraged friends working with cooperatives and hackerspaces to track their time, and (if they have a great skillset) to submit or log ‘receipts’ for their time, at their market rate, with the total of the invoice. The submit it with a note ‘payment cancelled, work is donated’. It’s a bit annoying, but it’s a good way to make sure the non-profit or community group values the work (and you can use it on your taxes in a lot of situations, for a deduction).

I think the Open Source community needs to start doing something similar when we pull in Open Source projects to use as tools, or as part of a product. We should run KLOC on the code and email the finance department with a note ‘Using Project X for codebase. We just saved ???K in development costs’. It’s a disservice to our community, and to ourselves, to not track the amazing amount of value Open Source tools give us.

Tags: , ,

Sprint Planning, now with disposable side-tasks!

Sep 23

Posted by FarMcKon in Code, Professional, Uncategorized | No Comments

TL;DR: When planning sprints, don’t pack your ‘nice to have’ features in the end. Pack 20% of each sprint with ‘Nice to Have’ or ‘candy’ features, so you can throw them away.

Planning sprints is a mixture of an art and a science. It’s hard to get all of the features you need (and some of the ones you want) stuffed into a development cycle. One of the tools I use to keep a project on track is making sure I have sacrifical features (or tasks) in every sprint, usually accounting for about 20% of the spint goals.

Lets say you have a project of 12 sprints, and 20 ‘dev points’ per sprint. A pretty normal breakdown would be to have some core features(red, 60%) and some should-have features (yellow, 25%) and a some nice-to-have features (green 10%). Oh and a little candy (blue 2%) as well as some tools (purple 3%) to build. I know this is a bit of a simplification, but I think if you know sofware, you get the gist. So go with it for a min.

Naive Sprint Packing

Now, your newbie SCRUM master will try to plan out a set of sprints for success. Naturally, she wants to get ‘Core’ done, then tinker on nice-to haves. So she plans the project as:

Looks nice right? Get hard stuff done first! If that seems like a plan for success, you probably haven’t run many sprints. To begin with, you can’t build all core fetures in a block. Any time you have interoperation, you have two choices: Define everything up-front (and fail) or make a basic design and evolve (and fail less). See Also ‘Waterfall Model Considered harmful. Core features are not as parallizable as ‘side’ features.

So, that red block of project will creep, or get delayed, just by the nature of development. Once that happens, each update to managment, and time you check your timeline, it will end with ‘and we are behind on Must-Have A,B, and C’. Every. Update. For weeks. As a hacker, you may know that is not bad, and it’s just lag from the front end, but to management and to your not-as-logical-as-logical parts of your brain, what they hear is ‘FAILSAUCE’.

Intermediate Sprint Packing

A more experenee scrum master will break things out a little more, and do something like this:

Again, it’s getting better. Now when things drift, they are more likely to be yellow items, so it’s not such a failure, and you can cast those off. But still, I bet 3 months pay that 99% of projects (yours) will be behind by sprint 8. Instead of red, Yellow items are failing, but still, there is fail.

Advanced Sprint Packing

A more experience scrum master is going to spread things out even more, and make sure, every step of the way, there are tasks that can ‘fall off’ a sprint, without killing the final deliverable.

Every sprint will go bad. Unless you are both awesome and amazingly lucky, almost every spint some core-task will go over estimate. Those red tasks are going to be on the plate almost every sprint. And every sprint you will have some Blue/Green tasks to throw away. Why? Because your estimates will be wrong, mistakes will happen, and you want to throw some luggage overboard, and make the product skinnier, instead of having late items the whole project long.

When you pack your ship, keep some extra luggage around to throw overboard during the journey!