On Bugs
By Mirano Galijasevic, Director of R&D @ Authority Partners
I have a zero-tolerance approach to software development. This means, I consider any level of bugs in software unacceptable.
Introduction
In the software development world, bugs are often viewed as an inevitable part of the process. “10% is fine,” they say. “20% bugs are expected,” you’ll hear. Some even go so far as to argue, “This time, 30% is understandable, given the number of features we’ve added.” These statements, though prevalent, are fundamentally flawed. As a software architect, I argue that the acceptable level of bugs in software should be precisely zero.
The rationale behind this zero-tolerance policy is rooted in the very essence of what software development is meant to achieve: creating solutions that work reliably and effectively to meet the needs of users. Every bug, no matter how minor, represents a failure in this mission. It is a flaw in the system that can cause disruptions, diminish user trust, and, in the worst cases, lead to catastrophic failures. The idea that any level of bugs is acceptable inherently lowers the standards of software quality and is a disservice to both developers and users.
Let’s use an example: you buy yourself a new car. It’s great, just what you wanted, has all the features you need, and looks fantastic. But there’s a catch: the brakes only work 90% of the time! Would this be acceptable for you? It doesn’t event have to be the brakes, it could be the engine, for instance. You are not in an immediate danger, but for some reason it would not start one or two times out of 10. Would you be okay with that? I don’t think so. So why should we be okay with bugs in software?
Why We Should Start Thinking About Bugs Differently?
The argument for a zero-bug tolerance approach is often met with skepticism. The most common counterargument is that bugs are simply an inevitable byproduct of complex software development. This one is really frustrating, as I firmly believe that people like this should not be working in the software development industry. With thousands of lines of code, dozens of integrated systems, and the ever-increasing complexity of modern applications, some believe it is unrealistic to expect a flawless product. However, I contend that this mindset is a result of complacency rather than necessity.
Today’s development ecosystem offers a vast array of tools and practices designed to minimize, if not eliminate, bugs from the software. We have static code analysis, which allows us to detect potential issues before they even manifest in the code. There are linters that enforce coding standards, automated testing frameworks that cover everything from unit tests to end-to-end tests, and continuous integration pipelines that ensure every change is thoroughly vetted before being merged into the main branch. When used effectively, these tools can dramatically reduce the likelihood of bugs slipping through the cracks.
Moreover, the adoption of best practices in software engineering, such as Test-Driven Development (TDD), pair programming, and code reviews, further reinforce the reliability of the codebase. TDD, in particular, shifts the focus from writing code that works to writing code that works correctly, as per the predefined tests. Pair programming introduces a constant peer-review process, where two developers collaboratively write code, reducing the chances of introducing errors. Code reviews, on the other hand, ensure that multiple eyes scrutinize every line of code, making it less likely for bugs to go unnoticed.
Given these resources, aiming for anything less than zero bugs is not justifiable. If we accept a certain percentage of bugs, where do we draw the line? What happens when that 10% bug tolerance leads to a critical system failure? Who takes responsibility when a “minor” bug causes significant business disruptions or, worse, impacts users’ lives? By setting the goal to zero bugs, we hold ourselves to the highest standard, ensuring that we deliver robust, reliable, and trustworthy software.
And Here Comes the Client!
Some might argue that striving for zero bugs is impractical, given tight deadlines and the pressure to release new features quickly. But this perspective overlooks the fact that bugs have a cost – and that cost is often much higher than the time saved by cutting corners during development. The time spent debugging, fixing issues post-release, and handling customer complaints far outweighs the effort required to build quality into the software from the start.
It gets even worse: the client communicates that they do not want to wait for the tests to be written, they want to have it in the production environment as soon as possible. This is a red flag, as it shows that the client does not understand the importance of quality in software development. It is our job as developers to educate them on the risks associated with releasing untested software and to advocate for a zero-bug mindset. If they persist, then you tell them: NO.
Here’s an analogy: you enter a Mercedes-Benz dealership and say you want to buy a brand-new Mercedes S-class from 2024. It is priced at around $130K. You tell the dealer you want to pay only $100K because you do not care about them testing all those many components in the car, so just ditch the testing and give me the car with untested parts, and I save $30K. I do not really want to pay for that extra testing, I am sure it would work reasonably well. What do you think they would do? Either politely ask you to leave or call the mental institution trying to track down from where you escaped. Why is that? Because testing and quality is not an extra feature that is an optional add-on: it is an intricate part of what you are building and is inseparable from the code that provides the business functionality.
Create user stories (PBIs) that already contain the unit tests and acceptance tests (yes, developers write unit tests and acceptance tests, not QA), and treat it as a single entity. Do not create separate “testing” tasks, as this will only lead to testing being skipped when the client is in a hurry.
The Role of the QA
The role of Quality Assurance (QA) teams is often misunderstood in this context. Many believe that QA’s primary function is to find bugs. However, this is a narrow view of their role. The true purpose of QA is to assert that the software and its functionality align with the acceptance criteria derived from the business requirements. In an ideal world, QA would not be finding bugs; instead, they would be verifying that the software behaves as intended under all specified conditions. If developers took full ownership of quality, QA could focus entirely on this verification process, rather than spending their time identifying bugs that should have been caught long before the software reached them.
When developers adopt a zero-bug mindset, they effectively take on the responsibility of ensuring that every line of code meets the highest standards of quality before it is merged. This approach necessitates a cultural shift within development teams, where quality is prioritized over speed, and thorough testing is considered a fundamental part of the development process, not an afterthought.
Continuous Integration (CI) and Continuous Deployment (CD) pipelines play a crucial role in supporting this shift. CI ensures that every change to the codebase is automatically tested and verified before it is integrated, catching issues early and preventing them from compounding over time. CD extends this by automating the deployment process, ensuring that every release is built, tested, and deployed in a consistent and reliable manner. Together, CI/CD pipelines create a safety net that allows developers to make changes with confidence, knowing that any issues will be caught before they reach production.
In addition to technical practices, fostering a culture of quality within the development team is essential. This means encouraging developers to take pride in their work and to view bugs as unacceptable failures rather than inevitable occurrences. It also means providing the time and resources necessary for developers to write tests, conduct code reviews, and refactor code as needed to maintain its quality over time.
While the goal of zero bugs may seem ambitious, it is not unattainable. It requires a commitment to quality at every stage of the development process, from planning and design to coding and testing. It requires the effective use of the tools and practices available to us, and it requires a cultural shift that places quality above all else.
To those who argue that a certain level of bugs is acceptable, I ask: where do you draw the line? How do you justify the impact of those bugs on your users? In a world where software plays an increasingly critical role in our lives, the stakes are too high to accept anything less than the best. As developers, it is our responsibility to deliver software that works as intended, without flaws, without excuses. The goal is not just to create functional software, but to create software that users can trust, knowing that it will work reliably every time they use it.
Conclusion
In conclusion, the acceptable level of bugs in software is zero. Developers have the tools, practices, and knowledge to achieve this goal, and it is time we hold ourselves to the highest standard. By doing so, we can ensure that our software is not only functional but also reliable, robust, and worthy of the trust users place in it. The role of QA should not be to find bugs but to verify that the software meets the predefined criteria, allowing them to focus on ensuring that the software delivers the value it was intended to provide. With a zero-bug mindset, we can elevate the quality of our software and, ultimately, the satisfaction of our clients.
Ready to elevate your software quality to the next level? Partner with us to build reliable solutions that your users can trust. Reach out to us via our web form or email us at hello@authoritypartners.com today and let’s create something exceptional together.
