David Heinemeier Hansson:
Disappointment occurs when expectations don’t match reality. And our expectations for software quality are profoundly unrealistic. Thus, lots of people are continuously disappointed — even enraged — by software bugs. They shouldn’t be.
The only reliable, widely used way to ensure impeccable software quality is to write less software that does less stuff, and then spend eons honing that tiny lot. Such an approach, however, is very rarely compatible with commercial success or even programmer motivations (despite what many may claim).
How do you think the market would receive the iPhone 7, if its headline improvement was cutting 1/3 of the features to shrink the code base so it’d have fewer bugs? Yeah, I thought so. While people may get excited in concept by “stop the train, we need to fix the tracks” directives for software development, it’s not what they would buy.
Well, but then there’s the argument: Apple is so rich, can’t they just hire more developers and testers to fix all the bugs? To paraphrase Frederick Brooks: No. Software development doesn’t work like that. Throwing ever bigger teams at problems usually just makes the problems bigger still.
Bugs are an inevitable byproduct of writing software. Sure, there are all sorts of techniques and potions that promise to decrease how many of the damn critters run about, but only the comically hyperbole pretends that complete eradication is possible.
Once we accept that simple fact that software = bugs, we can progress to understand why fixing them may not even be that important a lot of the time. The absence of bugs is simply one parameter of success in software, but not even close to the most important one (with some exception for life critical systems).