RSS

Advocate Zero Bug Policy in Your Projects!

Advocate Zero Bug Policy in Your Projects!

2020 12 01 head

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.

A change management board meets every few weeks and decide which bugs have now a higher priority and should urgently be fixed. It means an angry customer called someone at C level and 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 to properly administer 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.

2020 12 01 fix it or delete it

The rigorous Zero-baseline approach will force us to clean our code.

Let us categorize the bugs you have and deal with them accordingly.

  1. 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.
  2. 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 report. Treat such bugs as critical bugs.
  3. 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, don’t 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’s 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.

Finally, to ensure this system works.

  • The bugs that the team decides to fix must be prioritized over regular work and must get fixed now.
  • 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 write a unit test to reproduce the problem. You guarantee the users will never see again the same error. It is called non-regression testing and make 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?

References

See the excellent articles from Yassal Sundman working for the crisp company.