Customer development · Feature Development

Prioritization of bugs vs features?

Olesya Mayorova QA Lead - Towards Mars!

February 1st, 2017

Adding new features before the bugs of an old feature is somewhat fixed is basically regarded as bad practice in software development. Every bug you leave unfixed will cause problems in new features, will take longer to solve later cause you forgot what it was, put you in a lot of technical debt.

On the other side startups should focus on learning what features the customers need and ship as fast as possible, iterating as much as possible.

The key here would be saving time, learning early what the feature should be will save time but fixing bugs early before introducing new layers of programming will also save time.

So how should we prioritize between bugs and features in software startups and find a balance that works?

Kevin Brown Experienced IT Professional

February 5th, 2017

Who is leading your development and what project management approach are you using? If you are using scrum that answer is defined for you. If you are using waterfall, or RUP the answer is defined for you. If you are just winging it, then this is one of those things you need to answer for yourself.

Gabor Nagy Founder / Chief architect at Skyline Robotics

Last updated on February 1st, 2017

Ah, the old "feature creep" question... I struggle with it too. I have about 50 new features in the pipeline for EQUINOX-3D, 20 usable, 10-15 polished-enough for release...

Very true about technical debt.

It's a very important balance to maintain.

1) Show-stopper bugs (crash, data loss, unusable UI etc.) always before any new feature

2) Severe workflow slowdown issues always before new features

3) Memory leaks before new features, unless the customer is still trying to figure what he/she wants and only doing short test runs


Letting the customer know the limitations is critical. In the early phase, some bugs might not be show-stoppers, and it may turn out that the feature was not wanted anyway, so there's no value in fixing the bug (other than educational).


George Feil Director of Systems Architecture at Welltok, Inc.

Last updated on February 1st, 2017

Before I address this question, it's important to note that bugs fall into several categories, which determine their severity:

  1. Customer facing bugs that impair the usability of the application or result in data loss or corruption.
  2. Internally facing bugs that affect productivity of support staff.
  3. Software defects that affect application performance, maintainability, or limit the ability to add feature enhancements.

Bugs in category 1 should almost always take precedence over other work, since the last thing you want to do is create dissatisfaction. Bugs in categories 2 and 3 can be considered to be Technical Debt, which is analogous to financial debt.

Choosing to take on technical debt in the short term often leads to greater rewards in the long term if you can use it to gain more opportunity by delivering sooner. However, it's important to manage technical debt in the same manner as managing financial debt. Over time, the "interest" charged mounts up. I've witnessed first hand many organizations that accumulated so much technical debt that they eventually became paralyzed due to fighting production fires, and were unable to deliver any new features to market entirely.

Successful software organizations often, as a strategy, choose to take on some technical debt in order to deliver on time to meet an opportunity, and then devote a cycle to "pay off" this debt by focusing on bug fixing and refactoring instead of developing new features. It's also important to apply best practices in developing software (such as TDD) to avoid the unintentional accumulation of technical debt from bugs.

Stephanie Wagner Founder at Agile Bloom, LLC

February 6th, 2017

You definitely want to do a mix of bugs and features. Try to think in milestones/sprints (which can be a week or two long), and figure out what can be done during that time. A developer can work on a portion of a feature, plus X amount of bugs within a milestone. You want to make sure you include a mix of high and low priority bugs, because you don't want the low priority bugs stuck in limbo. It's up to you to decide what constitutes a "low" or "high" priority bug, but that setup seems to work best in my experience.

Danilo Del Fio I want to build my own future!!

Last updated on February 1st, 2017

My first thought is, according to Lean, that ne features are too important for the MVP that I'm building, but often simple bugs can have bad impact for the early adopters. So, I think that the right balance is to solve the bug that can improve the user experience and continue to focus on the features we need for the MVP

David VomLehn Why would you prefer a computer that breaks?

February 1st, 2017

It's like managing cash flow versus accrued value. You have to manage both. Accrued value is how much the company is worth and is the long term goal, but if you spend too much cash on things for the long term, your company will be unable to pay its employees and will die.


So, fix bugs like crazy because you will lose customers with buggy software. But do the new features, too, or you won't get new customers. It's all about balance. Kind of zen-like.


Oh, and get your developers to do things like code reviews to stop bugs from getting into the product in the first place. Code reviews offer so many benefits that it's hard to believe they aren't universal. There are nice open source tools for this, as well.