Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What would happen if we prioritised all bugs over all new features?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 77 posts

Re: Ask HN: What would happen if we prioritised all bugs over all new features?

#31

Post by sanitycheck »

drstewart wrote: post #7
bradwood wrote: post #5

This is a blunt and unworkable approach. Stopping the shipping of any feature because some bug exists doesn't take what is important into account: the user experience. A more refined approach is to triage the bugs into 4 or 5 levels of severity and then you might reasonably agree that at least all sev1 bugs must be fixed before new functionality is added. Just using a bug triage categorisation of "will fix" or "won't…

>A more refined approach is to triage the bugs into 4 or 5 levels of severity and then you might reasonably agree that at least all sev1 bugs must be fixed before new functionality is added. Of course, in practice this just means 3 or 4 levels of bugs that will never get fixed and languish in a backlog until the team / project gets re-orged and the entire backlog is wiped clean. Okay, I'm joking. Sometimes those bugs…

> Of course, in practice this just means 3 or 4 levels of bugs that will never get fixed and languish in a backlog until the team / project gets re-orged and the entire backlog is wiped clean.

I've never had much success getting a "won't fix" decision out of a PM or designer, and my time is too limited and valuable to spend debating it. If developers all know "low priority" means "never do" and "stakeholders" believe that their pet quibble will be fixed one day (even though they will never allocate time to do that) then work can continue in a sensible fashion.

Re: Ask HN: What would happen if we prioritised all bugs over all new features?

#33

Post by poniko »

In a mature product that needs to live long and continuously being developed I just do bug first and features later. I promise that users hate features not working more then features missing. The general idea that we always need to release new features are so misplaced, the best version of Spotify was the original release, the product has not really gotten better with time and more features, the actual reason why 90% use it is just working worse and worse...

Re: Ask HN: What would happen if we prioritised all bugs over all new features?

#34

Post by undreren »

jonathanstrange wrote: post #26
wkoszek wrote: post #25

Your role as a company is to maximize revenue. If presence of bugs makes you lose revenue by customer churning or burned-out developers leaving, fix bugs. If not, create new features. And define a bug as "thing that the customer complained about". If customers don't complain, it's either not a bug, or you are solving a wrong problem.

That's a bit oversimplified. Surely a bug that could lead to data loss needs to be fixed ASAP regardless of whether a customer complains about it or not.

The thing about bugs is their subtle influence on overall product quality.

It's like building a wall; if one layer of bricks is laid unevenly, at least a number of layers built on top of it will have to compensate. Usually, this compensation takes form in increased development times or increased complexity / convolution of new features.

Furthermore, it lowers end users' overall trust in the platform.

Both of these two effects will have at least some negative impact on profitability, though it may be lower than the increased profitability gained by adding new features.

I'm not saying all bugs should be fixed immediately at the expense of new features, but I've rarely been in a situation, where it felt "right" to ignore a bug indefinitely.

Re: Ask HN: What would happen if we prioritised all bugs over all new features?

#35

Post by tagspace »

veidr wrote: post #16

Microsoft rather famously tried this[1]. And it seemed to really help them. I've worked places that have tried it, too. It does work; in my experience, it literally always improves software quality. But I think it is like how pretty much all diets work, at first, but not over the long term. It becomes unsustainable, as the pressure to work on features grows. Continuing with my diet analogy, I now think of it like bul…

Yeah - that's a super interesing point about bug fixing leading to engineers wanting to quit.

Have you found a balance that works?

Re: Ask HN: What would happen if we prioritised all bugs over all new features?

#37

Post by martin-adams »

Assuming these are bugs which have workarounds and don't cause things like data corruption. Then it probably falls into the adage from advertising "50% of all advertising is a waste, you just don't know which 50%".

Another way to look at it is the delayed effect of doing nothing in either area. Bugs creeping in over the months and years may only become a problem when a competitor starts to be noticeably more stable.

Features that are delayed may have a delayed effect of a competitor getting ahead of you in the market and launching months before you'd be ready.

So I would say, "it depends". If you're in a growth market and are trying to capture market share, features might be best before non-critical bugs.

If you're in a stable market serving a huge amount of people, then fixing bugs has a much larger impact on your users.

You also have to consider the team and their morale over time. Too much churning through low value bugs can be demoralising where individuals might need some type of higher level thinking and creativity.

If it were me, I'd look at bugfix only sprints and adjust the frequency based on the above factors.

Re: Ask HN: What would happen if we prioritised all bugs over all new features?

#38

Post by lll-o-lll »

Yes you can do it, yes it can work. However as with all things there is nuance. This is a scheduling problem, and just like with a cpu scheduler there are degenerate cases you may need to avoid/handle.

Two problem cases likely to pop up.

1) Lots of fixing when a bigger refactor is required. A poorly written area of code, or a poor design, may be causing high churn and wasted effort. The solution I’ve found to this problem is to track defects by code area and review once metric exceeds heuristic.

2) A team choked on defects only for a long period of time. This obviously has many negative side effects. It tends to happen in really important component and require most experienced developers. Any new starters run for the hills when a team gets into this state, therefore compounding the issues. The solution to this (though this is just my opinion), is to never allow 100% of time over [fixed interval] to be spent on defects. No more than 50%. The bugs will still get fixed, just take longer, and new development is still happening.

Overall though, I think a “defects first” approach is the right one, just have a plan for these negative cases.

Re: Ask HN: What would happen if we prioritised all bugs over all new features?

#39

Post by kqr »

My main concern with the idea is that what counts as a "bug" is sometimes clear, but often subjective. A missing feature can easily masquerade as a bug in some organisations, and the policy you suggest would encourage dressing up missing features as bugs, leading to suboptimal information flows and feedback in the organisation.

Effectively, "I think this is important so I will argue you should work on this before that bug" is much better than "I think this is important so I will argue this is a bug."

Post reply on HN