DEV Community

Cover image for No Known Bugs and How to Get There
Jordan Brennan
Jordan Brennan

Posted on • Updated on

No Known Bugs and How to Get There

Does adding new features when existing features have bugs bother you?

Me too.

Managing software projects used to feel like I was a car salesman throwing in a set of winter tires (sometimes in Arizona!) while neglecting a burned out headlight. It's not dishonest, but it's not the level of quality and service I want to produce.

Even as my perspective of business priorities matured, this feeling never changed. I just can't bring myself to excuse or minimize it.

A few years ago at the direction of the CTO, I had an opportunity to pursue bugs with extreme prejudice and the team eventually whittled our backlog bug count down to zero. It was awesome! It changed the way I thought about quality and since then I've been of the opinion that software projects have no excuse for any bugs in the backlog.

No known bugs

Achieving true bug-free code is very unlikely, but reaching a point of no known bugs is possible. Two teams of mine brought their shared backlog down from 600 bugs into the 50's* and I've had four other teams get down to zero and regularly return to zero at the end of each sprint. Again, this didn't mean our software was completely bug-free, but it did mean all reported bugs were quickly resolved.

This did a few things for us. First, it felt good knowing we had cleaned house and customers were no longer experiencing those issues. Second, it sent a signal to everyone that this team cares about quality. We want what's already been built to be as good and perfect as the new stuff we're building. It also gave us a clear picture on the state of the product quality because our backlog accurately reflected it. And lastly, it made triaging more meaningful because we could honestly evaluate incoming issues without ignoring old bugs that may or may not be more important.

*Among other things, a four-time turnover in leadership allowed the backlog to balloon to 2,000 tickets. One more turnover - me - meant we didn't get bugs down to zero. Not sure if they ever did.

How we did it

1. Close old bugs

Close all bugs six months and older. Do it! Just close your eyes and do it. Then, take a moment to evaluate and aggressively close anything older than six weeks (roughly three sprints). Reasons to close can include duplicate, doesn't repro, will be resolved/replaced by future work, insufficient details. Don't over-invest yourself here; close everything that's not clearly actionable and be done with it.

If your judgement was wrong about any of those bugs (it will be), then someone will let you know and you can reevaluate at that time. No harm done. Alternatively, letting bugs linger in the backlog for months or years is poor project management and literally accomplishes nothing. It makes everything - triaging, planning, reporting, and analysis - harder and slower. It also sends a message to your team, stakeholders, and customers that quality and the user experience are not valued.

2. Fix the rest

Examine the remaining bugs and make a plan to fix them all. The goal is to resolve all known bugs, so it doesn't matter if you're left with 5 or 500. They are finally getting fixed!

If you don't have many, then just throw in a few over the next sprints and you'll be done soon enough. If you have a lot, then plan on carving out time for bug-bashing. Order pizza, queue Metallica, and have some fun smashing bugs. When you're done, take notice of the happy customers, happy stakeholders, and that fresh clean smell!

3. Set expectations

Set expectations for "No known bugs" going forward. Despite all the must-have quality controls like linting, unit tests, integration tests, and so on, a bug will eventually find its way in your software. In fact, your team might actually do everything perfectly, but a bug can still get in due to some external factor. Regardless, include resolving all bugs and returning to no known bugs at the end of each sprint as an equal part of your toolchain. Treat it like a tool, not an idealistic concept.

4. Be diligent

There will be doubters from the very start of your effort to clean up and get to no known bugs (saw it at two companies), but don't be discouraged. They will be pleasantly surprised when you're done (and they'll copy you!). After you reach zero, there's going to be the temptation to celebrate and relax, but if you're going to change the culture around quality you must have some diligence in you. There are, with very few exceptions, no good reasons for not returning to zero at the end of each sprint, so it really comes down to your team's commitment to quality and that starts with you.

I suggest always having a couple sprints ready and drop all newly reported bugs into the upcoming sprint. By sprint planning you need to have decided if any are not immediately addressable and move those to the next sprint. DO NOT BACKLOG THEM! Get answers now and make the decision now. The bug either gets fixed this sprint or next; otherwise you close as "Won't fix". Throwing bugs into the backlog for some nonexistent period in the future when the team will have magical time to just peruse the backlog for unimportant work is wishful thinking at best, but in practice it's worse than that. It leaves your team and stakeholders wondering where you stand on quality and leaves customers with a broken experience. Not good after all that progress you've made, so make your commitment and stick to it: No known bugs

Discussion (3)

bytebodger profile image
Adam Nathaniel Davis

Excellent post! Not only do I wholeheartedly agree, but I would add an extra sentiment: No known errors/warnings. One thing that drives me nuts about jumping into a legacy codebase is to see an avalanche of errors/warnings thrown in the console/logs. Once you start ignoring a handful of errors/warnings, it leads to a stream of messages that the devs eventually just tune out entirely.

jarjanazy profile image
Abdulcelil Cercenazi

Great stuff! I will share it on LinkedIn :)
I would also like to add, from my personal experience, to use more up-to-date technology and infrastructure which helps to speed up the development process.

yoursunny profile image
Junxiao Shi

What to do with Pull Requests that have been open for more than 3 years, and the dev is pushing one new commit every 3 months?