As a group, engineers are obsessed with quality. This I believe is what has made us great and helped us make big contributions to human progress. But this obsession isn’t always healthy and in fact on one particular area, errors it maybe downright damaging.
In this case we talk of errors in terms of bugs. A bug can simply be defined as a flaw in software that causes it to produce unexpected results.
Under this definition then quality is measured under the benchmark of number of bugs in the software. That is where we lose it.
This view of quality coupled with obsession to quality leads to engineering teams spending an obscene amount of time hunting for bugs. And even worse, the hunting is done in a linear fashion, ie from class to class in an arbitrary order say by alphabet.
Hunting bugs like this is wasteful and benefits no one, to understand why, we must look at the nature of bugs.
Developers make same mistakes
You and your team are not snowflakes! If there is an error you made, it has probably been made before by another team that uses the same tools that you do. It would be a wise investment to research on this errors to become more aware of their existence in your own codebase or even better yet to avoid making it in the first place.
The Pareto law states that 80% of the effects come from 20% of the sources. In this case only 20% of the bugs in your code will lead to downtime and other such non desirable events.
Identifying and focusing on this critical bugs ensures that you get the most bang for your buck.
As a corollary, the same law implies that if you find a class or module with bugs, its far more likely that other bugs can be found therein.
There is absolutely no single principle, method, language or even paradigm that will magically make your bugs disappear. This may seem like an affront on modern practises TDD, BDD, DDD etc but actually it’s a confirmation that if there did exist a particularly effective approach, you would know about it.
So we have concluded there can be quality with an acceptable error rate for some parts of the code, but then how can we redefine quality?
A good way to think about it would be to think of the purpose of the software. In this case we consider bugs not in their own right, but in the context which the bug has an impact on reliability of the product.
Understandably this approach is harder, you can’t just count the reds to greens, but ultimately it will lead to more productive use of our engineering resources.
What is your philosophy on bugs? Talk to us on the comment section below.