Software is NOT like 6-Sigma

Six-Sigma, ISO 9001, and the like are processes used in mass-production lines to ensure vanishingly small errors.

It makes sense, if you're Dunkin Doughnuts producing 350,000 doughnuts per day. The problem is that some people insist that these processes should be applicable to software development.

"Why can't software development be more like electronics development?" "Six-Sigma means almost zero defects on massive scales, so why can't we use these techniques in software?" These are the kinds of questions you get.

And of course some people actually try. Defense contractors, CMMI devotees, and behemoth government-like organizations try.

But software development isn't like making 350,000 doughnuts. With doughnuts the thing you're making is completely understood and measurable, and the problems come in copying the Platonic form zillions of times without error. Difficult, I agree.

But in software you're making ONE, massive, complex, changing, ill-understood thing, and making it ONCE. When we ship copies, they are perfect copies. Unless you're burning DVD's, in which case the act of burning might be best handled under Six-Sigma.

The problems are completely different.

For example, our software interfaces with other tools. When those tool vendors release new versions, it's possible that they break our interface with them. Therefore, even with perfect copying and no existing bugs, our software will STILL BREAK!

For example, in software requirements are supposed to change. Possibly during development, definitely afterwards. Once it's decided that a bridge is supposed to go from A to B, it's done. Even if that decision turns out to be wrong, everyone accepts that either we should nuke the bridge or finish it anyway -- there's no concept that we should rebuild the bridge in mid-air and still make schedule. Not so in software -- this happens all the time.

For example, software's purpose changes over time. A doughnut is always supposed to be a doughnut. A home Wifi router gets small firmware updates, but no one expects it to do more than what it did on the they day bought it. Most software projects change radically over their lifecycle. Windows 1.0 barely solved any problems; Windows 95 changed everything, and Vista barely looks like it came from the same company that released XP. Even Google Search -- the algorithms, advertising, and company goals are nothing like they were when it first became well known. But Dunkin still primarily makes doughnuts (and coffee), and we expect nothing now from 50-year-old bridges than what we originally expected.

There's more. Software developers themselves are a different breed than workers on the doughnut assembly line floor. The world-view and skills required for software development turns over at least every 10 years (more often if you want to change jobs). And sometimes a new feature really is more useful to a customer than a bug-fix, though rarely does anyone admit it.

The point isn't to say that it's OK that we have bugs in software, or that we can't do anything about, or that we shouldn't try. It's just that blindly applying process from other disciplines is not the answer.