Writing software is hard. Make that very hard. The reason why is because computers are not smart at all when it comes to taking what you meant over taking what you said. They’ll take what you said every time. And that is the root cause of a very large number of bugs. No computer ever suddenly piped up and said ‘hey boss, I know it’s early and you haven’t had your first cuppa yet but I think what you’re typing right now it total nonsense’. We’re a ways away from that sort of interaction (fortunately, because I think as soon as that happens people like me will join the leagues of the unemployed).
Anything at all that helps to get bugs under control is usually hailed with great praise because bugs are nasty. They disrupt your customers experience, they make you look silly, they can cost money (sometimes vast amounts) and in some cases they can cause people to die. There probably aren’t many instances where bugs were thought to be beneficial (though there are some and these gave rise to the ‘it’s not a bug, it’s a feature’ meme).
There is one important thing that you really have to understand thoroughly before you set out to get the bug plague under control: reducing the number of bugs in code comes at a price, and no matter what you will do the cost of getting to ‘0’ bugs is so large that you will not be able to afford it.
Examples of situations where budgetary considerations are secondary to writing code without bugs are found in aerospace and aviation, as well as embedded software for use in medicine and for instance the control of power plants, weapons and so on.
And even there the trade-off holds true, the software is not bug free, there is just a reduced number of them.
The reason why this is the case is tricky, but if you think about it for a while you’ll come to the same conclusion as everybody else has that has studied this for more than 10 minutes: different bugs may be susceptible to various approaches but there are always exceptions. So one method of