Unfortunately, it looks like you are using an outdated browser.

To improve your experience on our site and ensure your security, please upgrade to a modern browser such as Chrome, Firefox, Safari, or Edge.

Skip to main content

Blog Making Great Software

Bug vs feature: What’s the difference and which to prioritise?

Last updated:

In this post, you’ll learn the difference between a bug and a feature and which your team should prioritize. You’ll also discover why developers prefer to build new features rather than fix bugs.

Let’s dive in.

  1. What is the difference between a bug and a feature?
  2. Bug vs feature: which to prioritise?
  3. Should you fix ALL bugs?
  4. What if your developers want to work on new features?
  5. Conclusion
bug vs feature

What is the difference between a bug and a feature?

The main difference between a feature and a bug is that a feature is intentional and a bug is accidental.

Bugs are programming errors

In software, a bug is a glitch that prevents the product from working as intended. Bugs usually come from human error: a design flaw or programming mistake.

Bugs may cause software to crash. They may lead to security breaches. They may prevent customers from completing a user flow.

Not all bugs are significant. An error that causes a button to break over two lines of text on smaller screens is unpleasant. But it doesn’t affect the product’s functionality.

example of a bug: "authentication failed, please contact the administrator"
Example of a bug (photo by Markus Spiske)

Features are what software can do

Features define how a product works.

Can users comment on each other’s posts?
Can they use Apple Pay?
Can they use the product offline?

These are all examples of features.

Overwhelmed with customer feedback? Try Feature Upvote.

We make easy-to-use feedback boards that let your customers submit and upvote feature requests – all in one place.

Feature ideas can come from within a company or from the end-users themselves. They are collected, managed, and prioritised in feature request software or spreadsheets.

Too many features can complicate a product and sabotage the user experience. That’s why good product managers think of desired outcomes before plotting new features.

Example of a feature in Feature Upvote
Our software, Feature Upvote, allows users to vote for feature requests. That’s a feature.

Can bugs be features?

Sometimes, bugs can look like features and vice versa. This can lead to bugs becoming part of a product.

Sarah and her team ship the latest version of Product XYZ. They expect it to work a certain way. But when it goes live, something isn’t working as it should.

But customers don’t know it’s a bug. In fact, they think it was meant to be this way. And they love it. So Sarah lets it be and calls it a feature.

If users don’t love it, then the bug is just a bug. And Sarah has to do something about it.

"it's not a bug, it's a feature" reddit thread
Reddit thread about features that started as bugs (full thread)

Bug vs feature: which to prioritise?

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

Joel goes as far as saying that successful software development depends on fixing bugs first. He illustrates with Microsoft.

When Microsoft prioritised product features over bug fixes, their teams experienced disastrous results. So they changed their approach and adopted 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.

Joel Spolsky in The Joel Test

Prioritising bug fixes also means your product is always ready to ship. Your lead times are shorter and your team more agile.

Say you need to build a feature in a pinch. Because your product is bug-free, you will be able to ship the new version right after you complete the new feature.

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

The Joel Test says to fix bugs before writing new code

Should you fix ALL bugs?

What if the bug in question is hard to fix and doesn’t affect many people? You might argue it is better to build a feature that will help hundreds of users than to fix a bug that bothers a dozen.

If you apply this logic over and over again, you’ll end up with a product riddled with defects. Your users will have a terrible experience and they will churn.

Your product is much better with a few bulletproof features than a mess of shaky ones. They will be well-designed, well-tested, and hardened thanks to rigorous bug fixing.

Features attract new users. Bugs repel existing users. (click to tweet)

What if your developers want to work on new features?

Fixing bugs when feature requests are flooding your feedback board is frustrating. It is the brutal reality of software development.

Novice product managers often assume that building a feature is quick. They underestimate how long finding and fixing bugs in the feature will take.

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 bugs.

You’ll often hear developers joke: “It’s not a bug, it’s a feature!”

But a product manager needs to be firm in making sure bugs get priority every time.

Conclusion

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 Feature Upvote.

You’ll get a board where your customers and team members will be able to add and upvote product ideas. The best suggestions rise to the top, making it clear for your team what to build next.