John Romero spoke about the early principles of ID Software and one of them is to fix bugs once you find it without delay.
Ask HN: What would happen if we prioritised all bugs over all new features?
51–60 of 77 posts
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#52How much money are the bugs costing the company vs. how much money (time) it costs to fix them? Classify your bugs on scale of impact on end users, profit loss and other important factors. Depending on the amount and scope of the bugs, one idea is to have a bug fix sprint, I use that term loosely, essentially a time box to work on bugs and make things nicer. When the time box is over get back to feature work.
Using libraries and frameworks gets you speed in delivery because you don't have to write that stuff yourself, the downside is there are likely bugs in that software or in how your system interacts with it. No software will be "bug free", striving for that is a fool's errand.
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#53We did releases that were only bug fixes and maintenance. There can be a long tail of bugs in a complex system, most of which are relatively harmless and only occur in very rare situations; it’s hard to justify fixing these when paying customers are asking for a new feature. Also you’d be surprised at what gets classified as a bug when you apply this. Ultimately though, everybody does this. Critical bugs get fixed fi…
Your point on intellectual honesty really resonates.
I personally like the idea that for every bug you either: a) fix it with highest priority, or b) mark it as "won't fix".
I think this would really force you to make a decision on a bug, rather than adding it to some never ending list of lists.
If a bug is worth fixing, it will come up again
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#54We did releases that were only bug fixes and maintenance. There can be a long tail of bugs in a complex system, most of which are relatively harmless and only occur in very rare situations; it’s hard to justify fixing these when paying customers are asking for a new feature. Also you’d be surprised at what gets classified as a bug when you apply this. Ultimately though, everybody does this. Critical bugs get fixed fi…
Sometimes a feature request is considered a bug by customers: this product would be easier to use if we could do X, and the competing product lets us to that.
Totally agree. Wether something is a bug should definitely be decided by the team, not the customer.
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#55- New features help close sales. - New features also add tech debt, complexity, cost, bugs, makes you slower, and will lose you some sales that way. - At 0 features you really need to implement features instead of messing about with the bugs in the devops scripts. - At e.g. Windows scale, maybe stop messing about with new features nobody asked for and fix some bugs, yes. - In a Laffer-curve-like effect, there must be…
I like the curve idea. Makes sense.
When customers aren't signing up because of lacking feature -> build features. When customers are churning because of bugs -> fix bugs. Else -> somewhere in the middle
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#56Microsoft 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…
I worked at Microsoft later than that and my team (most of the times there is no "Microsoft did X", it is a team, department or product decision) tried a variation on Zero Bugs policy. We either fixed immediately, closed as won't fix (and here there's the question of correlating future related bugs with different symptoms) or turn into a new feature request of the fix requires bigger changes but is still needed. It worked for a while, but as others said it is hard to maintain this policy over time for a complex product.
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#57On a sufficiently complex product it is impossible to fix all known bugs, even classified as will fix. Another issue - it will take so much time that your company will be left behind by the competitors. Maybe less so in the web, but with hardware it's a question of multiyear contracts, so getting abandoned by a big customer in favor of a feature rich competitor may mean that you won't get a second chance with them an…
> On a sufficiently complex product it is impossible to fix all known bugs
You really think so?
Surely it's just a matter of picking a sufficiently high bar for "will fix" and then focusing some time on it.
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#58Yes 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 pr…
Really good point about bug fixing affecting engineer morale. Super important.
One (arguably positive) side-effect I'm wondering might be possible is that: if bugs are always prioritised first .... and engineers are often very creative at solving problems .... will they perhaps come up with creative ways to reduce bugs in the first place?
Or, it might go all wrong -> and we create a dangerous culture of "swallow that exception" :D
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#59We did releases that were only bug fixes and maintenance. There can be a long tail of bugs in a complex system, most of which are relatively harmless and only occur in very rare situations; it’s hard to justify fixing these when paying customers are asking for a new feature. Also you’d be surprised at what gets classified as a bug when you apply this. Ultimately though, everybody does this. Critical bugs get fixed fi…
I think you can have alternative: bugs are either critical or "non-critical". Non-critical end up in the backlog, but are classed before improvements and before "non-critical" features.
How does it really work: let's say you have 2 week sprints (quite standard). Then you break the agile/scrum "story points" and velocity: it isn't usefull for your team (but might be for management). After quick estimates, each member take what he estimate to be a week, a week an a day of work on critical bugs, then critical features. Because let's be honest, you alway have more "critical" stuff to do each week, and will never get your backlog small enough to reach non-critical stuff.
Once you're done with your "critical task", depending on the time you have left, you take a non-critical stuff, in preference in backlog order if you're senior and long-time IC (lot of bugfixing), preference to "i'm sure i know how to do that" then "unknow project but seems easy enough" for juniors, and seniors who just arrived.
Having a gigantic backlog isn't an issue as long as each task are assigned to a product and a Major version: that will allows you to discard those tasks easily if the product isn't sold anymore of if the version changed.
Re: Ask HN: What would happen if we prioritised all bugs over all new features?
#60We did releases that were only bug fixes and maintenance. There can be a long tail of bugs in a complex system, most of which are relatively harmless and only occur in very rare situations; it’s hard to justify fixing these when paying customers are asking for a new feature. Also you’d be surprised at what gets classified as a bug when you apply this. Ultimately though, everybody does this. Critical bugs get fixed fi…
It is also useful to have handful of "easy to fix" bugs on backlog to use as on-boarding for new developers .