Advocate Zero Bug Policy in Your Projects!
At many customer sites I visit, I see a lot of effort being put into classifying and managing bugs.
Their bug list may contain more than a thousand items. All are neatly documented with screenshots, ways to reproduce the problem and a severity and impact classification. In the worst case, a specialist has worked hard and estimated the effort to correct each of these bugs.
A change management board meets every few weeks to decide which bugs have a higher priority and should urgently be fixed. It means an angry customer called someone at C level. Now his request must be handled. Some of these bugs were discovered years ago. The discussion can take hours and involve up to ten people. Clearly, many expensive hours have been invested in properly administering these bugs.
Creating a list of errors provides an organized inventory of technical debt. Spending time on evaluating and administering bugs with the goal of tracking them is just wasteful. Please stop doing such activities.
The solution is elegant and simple: Implement the Zero Bug Policy.
Stop Managing Bugs, Start Focusing on Quality!
How to transition?
Zero-Bug policy does not mean bug-free code in production; it means striving to eradicate all known bugs.
When a bug is found, tests are created before the bug is addressed.
A bug is not an error in logic; it is a test that was not written.
— Ken Auer
eXtreme Programming
eXtreme Programming
The rigorous Zero-baseline approach will force us to clean our code.
Let us categorize the bugs you have and deal with them accordingly.
-
You have a few critical bugs that crash the system or don’t have a workaround. Prioritize and fix those. Your customers will be very thankful. Fix at least a handful of these critical problems in each sprint.
-
You own a big set of bugs that are already in production. They have been in your bug tracking system for quite a while. Delete those. If it is a costly problem, your customers will fill a new report. Treat such bugs as critical bugs.
-
Establish a software craftsmanship culture. Stop delivering products with known errors. Correct them before delivery. Your product owner should reject any feature with known errors.
Bugs have a tendency to become obsolete pretty quickly in applications that are updated frequently. The steps to reproduce them become irrelevant, the functionality changes, the impact of the bug often gets lower.
Please, do not waste your time trying to update the documentation related to these bugs. You may lose a few valid ones, but trust me, someone will report it again if it is still happening.
Clean Code and Happy Customers
Bugs are like water leaks.
If you leave them for too long, they can spoil your merchandise and slow down your business.
Follow these steps to ensure this system works.
-
The bugs that the team decide to fix must be prioritized over regular work and must get fixed now. In Scrum, the product backlog item containing the bug has the highest priority.
-
In the beginning, there will be more bugs to work through, as some bugs that were deleted will be reported again.
-
As the team shifts its focus to improved quality, there will be fewer of them. This is truly a binary system with no wiggle room.
-
Bugs are either fixed now or deleted, there is no severity and no haggling about the classification of a bug! Good practice is before fixing the glitch to write a unit test to reproduce the problem. You guarantee your users will never see the same error. It is called non-regression testing and makes your customers very happy.
-
Are you ready to shift your focus from managing bugs to ensuring quality? And if not, why should I buy your product?
Links
See the excellent articles from Yassal Sundman working for the crisp company.