FYI – Very interesting Sunday read - The Economics of Perfect Software
Ask 100 CEOs of software companies if they want to ship software with bugs. What will they say? 50 won’t answer at all, saying something about how bugs are a huge problem in the industry that needs to be addressed; 40 will say “Of course not!” and promptly call their shark tank in preparation for a lawsuit; 9 will hang their heads and say “we can’t help it”; and that last 1 will look you straight in the eye and say “Absolutely.”
Software can’t be written bug-free, so if you want to ship perfect software you have to fix the bugs that burrow their way into your code.
As you’d expect, the more time and money you throw at fixing bugs, the more bugs you’ll fix. But, unfortunately, our old nemesis from economics, the Law of Diminishing Returns, applies to this process. Formally, the Law states that “the marginal production of a factor of production starts to progressively decrease as the factor is increased, in contrast to the increase that would otherwise be normally expected.” In regular-people English, that just means that how much you get out of a process isn’t the same as what you put in across the board. Instead, you end up with a quick ramp on output at the low end of input, and a long tail on output at the high end of input.
For example, imagine a program has 100 bugs, and we know it will take 100 units of effort to find and fix all 100 of those bugs. The Law of Diminishing Returns tells us that the first 40 units of effort would find the first 70 bugs, the next 30 units of effort would find the next 20 bugs, and the next 30 units of effort would find the last 10 bugs.