As a software product manager, how should your team prioritise between bug fixes and adding new product features?

Back in 2000, Joel Spolsky created the Joel Test, a 12-step list to better code. Step 5 on the list is “fix bugs before writing new code”.

Joel claims that a preference for fixing bugs first is necessary for successful software development. Microsoft adopted this habit in response to the disastrous results their teams experienced when they prioritised product features over bug fixes:

Microsoft universally adopted something called a “zero defects methodology”. Many of the programmers in the company giggled, since it sounded like management thought they could reduce the bug count by executive fiat. Actually, “zero defects” meant that at any given time, the highest priority is to eliminate bugs before writing any new code.

Fixing bugs as your first priority made sense in the year 2000 and it still makes sense today.

What if the bug is hard to fix?

But what if the bug in question is hard to fix and doesn’t affect many people? You might argue that it is better to add a new feature that will help many users, rather than spend the same time fixing a bug affecting only a few users.

The problem with this logic is that when it is applied over and over again, you’ll end up with a product that is feature rich but riddled with defects. Many of your users will have a terrible experience.

In general, features attract new users and bugs repel existing users. If you don’t fix bugs first, your buggy product will have terribly high churn. Word-of-mouth, if any, will be the negative kind where people warn their friends not to use your product.

Your product is much better with just a few features that are well-designed, well-tested, and hardened through rigorously prioritising bug fixes.

The slow pace of development can be frustrating when you have customers requesting feature after feature. This is the brutal reality of software development: coding a new feature seems to be quick, but finding and fixing all bugs in the feature takes way longer that novice product managers expect.

What if your developers want to work on new features?

Your developers are likely to argue in favour of new features over bug fixes. That’s because starting a new feature is more enjoyable for developers than hunting down bugs. Few developers would prefer to spend a week tracking down and fixing a hard-to-reproduce bug when they could be doing a new and interesting feature. A product manager needs to be particularly firm in making sure bugs consistently get priority.

The “Joel Test” describes another advantage of prioritising bug fixes: it keeps your software in a “ready to ship” state at all times. When you do need to respond quickly with a new feature due to external factors, your almost bug-free product will be ready for instant release once the new feature is added.

Do you want to make software that your users adore? Then prioritise bug fixes over new features.

Have you fixed all your bugs and want to know which new features to add? Then try us out!

Here at Feature Upvote we provide you with a product ideas board where customers and team members can add and upvote suggestions, so the best rise to the top.