No Bugs != Quality

By Chris Clark, 01/29/2012, in Engineering management

We're Hiring!

My company, Grove Collaborative, is hiring full-stack engineers. If you like what you read here, and want to work on similar problems, email me ([email protected]) or learn more.

A low bug count is not a good indicator of quality software. Lack of typos and grammatical errors is not indicative of a quality book.

If your software has nagging "quality problems", driving the open bug count to zero probably won't be much help (not least because it only addresses the bugs you've found - not the multitude inevitably lurking in obscure code paths). If the software is hard to use; if it doesn't solve the problem it was designed to solve; if it's slow; if you pay a huge engineering tax whenever you make a change because the code base is spaghetti; then bug count may not be your problem.

In fact, a high bug count isn't even a reliable indicator of poor quality. Google Chrome, the world's second most popular browser, has over 32 thousand open issues.

I'm all for keeping bug counts low - fewer bugs is better than more bugs - but if you have a large number of infrequently-reported bugs, then bug count is little more than a vanity metric. 

Fixing every outstanding edge-case bugs will not create happy users out of net detractors. Playing whac-a-mole with bugs is ineffective. Quality issues demand stepping back and taking different approaches. Bugs are symptoms, not causes.

Like what you read? Join the newsletter and get updated when there's something new.