From The Economist on the software industry:
An industry rule of thumb is that a bug which costs $1 to fix on the programmer’s desktop costs $100 to fix once it is incorporated into a build, and thousands of dollars if it is identified only after the software has been deployed in the field.
The larger idea about fixing things early in its lifecycle is interesting. Take hiring/firing. We almost always wait too long to fire someone. When was the last time you heard someone say, "I think I fired him too soon." The longer we wait to correct a screw-up, the more expensive the mistake becomes. Yet stubbornness or overvaluing sunk costs often keep us from acting as quickly as we should.
(Here’s my Rule of Thumb wiki.)
That rule of thumb is really only valid for packaged software, it doesn’t apply to web based software. The cost of fixing a bug after the code is pushed to the web site is not much more than fixing it before it pushes. However if you push much more often and with less lag between having an idea and pushing the idea, you can get significantly better feedback and market traction. This is one of the foundations of “agile” development. The old rule of thumb is talking about what is often called “waterfall” development.
However your comment about firing early is true. If someone isn’t doing well, its best to get them to leave and find a job that is a better match for their skills as soon as possible. Making this a systematic company-wide approach is hard to get to, but worth it.
amen to that.
It depends on what stage the business is. Startups can’t afford to wait till every last bug is fixed. Chances are, they wouldn’t even recognize all bugs before they are outdone by nimble competition. Over engineering is suicidal in that stage. As Guy Kawasaki says – Don’t worry, be crappy !
In the licensed software world, it’s not always possible to fix bugs early because of their relatively longer shelf life. Changing regulatory and compliance norms call for occasional tweaking of the features that were perfect when coded.
Then enterprise CEOs have the Wall Street to please. To qualify for liberal stock grants pegged to performance, they have to show revenue and earnings growth. There you go, new versions with cosmetic brush-ups just like your new car full of knobs that you hardly ever turn.
On firing people, early fixes are always good. But if you do it way too often, it’s the recruitment process that needs fixing.
I’d like to take Adrian’s comment further. I agree with the general principle that catching errors early saves money. However, the rule of thumb overstates the amount of savings, even for packaged software. The rule of thumb was first formulated in the era of punch cards. Things have changed since then, though not always as much as people suppose.
The same can be said for going to the doctor. You never hear anyone complaining, “Man, I wish I would have waited a bit longer before I went to see the doc.”
Prevention is so much cheaper than treatment. Plus, the psychological costs of not having to worry that you’re dying are a major incentive as well.
-Cameron
It’s funny that you talk about “overvaluing sunk costs”, because if you wanted to be perfectly rational, you wouldn’t value sunk costs at *all*. Here’s a handy diagram.
Flawed thinking:
“We spent two weeks finding and hiring this guy. That was a lot of effort.”
Correct thinking:
“If we fire this guy, then we’ll have to spend maybe two weeks finding and hiring someone to replace him. That will be a lot of effort.”
Flawed thinking:
“I’ve spent half a year working on this project. I can’t quit now.”
Correct thinking:
“Well, let’s see. I’ve got six months of work done on this project done by my previous self. Should I continue with it, or move on to something else?”
A handy heuristic for avoiding the lure of considering sunk costs is to periodically imagine you’ve been teleported into your current situation.