Every software company needs a Chief Bug Officer. Learn how bug ownership improves quality, speed, and customer trust.

All software has bugs, unfortunately. That’s because software is invisible, and you can ship a problem as big as shipping a car with three wheels. In contrast to the flawed car, you don’t see the flaw in software, even if you take testing and quality assurance seriously.

Not all issues reported by customers as bugs are bugs, but all customer issues need to be taken care of — ideally instantaneously, realistically within a reasonable time.

Irrespective of how small or how big your software company is, how can you deal with bugs that impair the quality of your software product?

The Worst Option: Features over Bugs

At Yonder, we used to have a CTO who once bluntly said that bugs don’t matter, only features matter. Whilst, indeed, innovation often stems from new features, never forget that your product should solve a problem for your customers. And if they are bogged down by bugs, you possibly create a new problem for them.

Needless to say this person is no longer with us, and needless to say it took us quite a while to get the number of bugs down to reasonable numbers. And we’re still not at zero bugs, unfortunately.

The Second-Worst Option: Bugs over Features

You could now prioritize bugs over features, tackling all bug tickets before working on the features. Whilst this would greatly increase the stability of your software product, it affects customer satisfaction in two ways: On the positive side, customers will appreciate the stability of your product and the fast turnaround time for bug tickets. On the negative side, they will get impatient with new feature requests and feature improvement requests.

Furthermore, your competitors will push on and introduce new features, so you will lose your competitive edge if you just sit still on your current feature set.

Getting Better: Bugfix Sprints

So you need to strike a balance between bugs and features, no matter how you do this. In the past, we used bugfix sprints that we scheduled after a few feature sprints, where we focused on fixing as many bugs as possible in a sprint and not working on features during that time.

On the positive side, this is a productive way to get bugs out of the way. On the negative side, this still means long fix times, as you can’t schedule bugfix sprints all the time. Besides poor customer satisfaction, the bugfix sprint system also yields technical issues: The longer a bug is around, the harder it is to reproduce and hence to fix it.

Even Better: Take Ownership

Rumor has it that at Apple, bug review boards are led by very senior executives, sometimes even by direct reports of Tim Cook (casually, they refer to that as “T-1”). Once a bug is on the radar of the bug review board, it has ownership, and then it gets done.

Yonder is not Apple, of course. However, I tried to adapt the bug review board approach for our 30-person SaaS company. I am joining the daily meetings of one of our development teams every day. Instead of a separate bug review board, I go through the backlog and the bug tickets every night, and I note down a few bugs I want to focus on. Then we speak about those bugs in the daily meeting, and I take them off my list only when they are fixed. Only to replace the fixed bugs on my list with unfixed ones.

So Tom the CEO is now also Tom the bug owner. In contrast to Apple, bug ownership is “T-0” at Yonder.