Ideas in Wiring

Shipping Software

I became a "professional programmer" when I was 17. "Professional" because a freeware app I made got put in a floppy-disk based periodical and I got paid money for it. How cool. (Holy cow I found it KeyCapsGS - first published in 1988 I believe).

So since 1988, I've had to deal with the question of "when the heck is software done?" Well, metaphorically, software is never actually done. There's always 2.0, 3.0. But when you're working on 1.0, when do you decide to ship it?

As with all art forms, it depends on who's looking at it. I hope the software that controls the brakes of my car has zero bugs in it. Then again, all I really want is that there are no bugs that ever prevent me from stopping. So even safety critical software has some sort of acceptable bug threshold. If my screensaver applet crashes when I change modes, I may not even care.

So my answer is: you ship it when the quality level is acceptable to your customers (and possibly regulatory bodies that have some sort of say in the matter)

The concept of "acceptable level of bugs" doesn't sit with some people well. But again, it's a matter of perspective. The article quoted a study that found

...two separate people dissected one particular Microsoft program and found out, to their shock, that it was over 2,000% larger than it should have been.

Maybe Microsoft programs are indeed "bloated". But so what? Probably 100 people in the world really care enough not to buy their software. But if Microsoft went and rearchitected some application so that it met those folks' mythical standards, they probably would lose tens of thousands of sales to satisfy those 100 people. So calling software "done" isn't just a technical decision, it's a business one.

So the key is to understand your customer base. Understand what they need. Understand what they want your software for. Is it being used in a safety critical system? Is it being used in a screensaver? Your biggest risk in software is misunderstanding the quality that the customer expects and giving them something different. If they expect more and you don't give it to them, they'll avoid it like the plague. If they expect less and you give them more, you may have wasted development time that a competitor used to snatch those customers away.

LabVIEW 7.1 has a great reputation and we're all quite proud of that release. But not all releases hit the "meet customer expectations" mark. I presided over a version of LabVIEW that had a bug "fix" in it that caused an even bigger bug than the one it fixed. Whoops. (Fortunately we pulled the release and fixed it before anyone noticed) But in the end, our goal is always to make you happy.

posted by Joel @ 2:40 PM