If your company is a feature factory, it is not a good idea. If the business is stable and has a clear scope, you should be OK.
Ask HN: What would happen if we prioritised all bugs over all new features?
21–30 of 77 posts
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#22I think MacOS did it once (around 2009-2011) where they made a release that contained pretty much only bug-fixes. Made a lot of users happy.
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#23I'd love if the industry could have some sort of bugfix-only-month. Just one month per year where everyone goes off to fixing something, and new features are forbidden.
In fact, I'd love something like this so much, I'd even be willing to sponsor efforts like that with a bit of cash.
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#24Adding new features will introduce new bugs in your already "bug fixed" parts.
Therefore go for release cycles. Lock features, fix all bugs, then release the version. Repeat for every cycle.
You might be forced to release with a few bugs. The conventional procedure is to publicly document the known bugs for each version.
If you are fighting fire with bugs, then you don't have stable product yet. Cut off up to a reasonable feature set and fix all bugs when you want to release.
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#25Your 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.
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#26Your 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.
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#27Your 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 seems short-sighted. Just because a customer hasn’t complained about it doesn’t mean it isn’t a bug.
I’m not disagreeing that customer complaints are important for prioritisation, but the problem isn’t quite as first-order as that.
In an extreme case, imagine you found a bug that corrupts data if a customer name begins with z. Would you not fix this bug just because you don’t have any customers whose name begins with z?
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#28If you're driving users away with some major bugs you better try to fix them ASAP. But chasing "100%" is usually a bad business strategy IMO. When you have an absolutist policy like that you risk losing a lot of momentum over something small that isn't driving much value, just to satisfy the arbitrary policy.
Is it worth not making progress on any new features, all because of a smaller bug or issue? Can just one person work on the small bug while the rest of the team starts a new feature?
Sometimes the best bug fix is a new feature that depreciates the bug, so be sure to consider the estimated lifetime of the bug if you keep progressing your platform and maybe don't spend too much time fixing things that will be soon phased out anyways, unless they're really major issues that are rapidly hurting the business or reputation and need immediate fixing.
If you really want to halt all new features, I might try putting it on a calendar. Maybe you can afford 1 month, 1 quarter, or half a year on just bug fixing but eventually you have to keep moving forward in some way. Unless your platform is already pretty feature complete (which it doesn't sound like it is) you might do more harm than good when delaying your next core feature releases.
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#29Your 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.
Many bugs don’t cause customer churn short term, but it does long term. And that is difficult to measure. They might not tell you for all kinds of reasons.
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#30Your 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.
That's risk management. If the risk of losing the customers' (or future prospects') revenue is big enough, you should fix the bug. There might also be the risk of fines.