Hacker News Reader

Comment by didibus | Hacker News Reader

Maybe this is a naive question, but why couldn't you just pick a bug at random, fix it, and move to the next? You said eventually you worked through all issues in about a year of time. How did having the issues prioritized from the get go really mattered, if you ended up closing them all anyways?

If I had to guess, the magic trick was simply investing in tackling all the bugs one after another for a year until they're all closed out. Maybe you needed to triage them all to convince people to invest in doing this?

View on HN

It's a good question. i.e. if it takes a year to fix all bugs then why does order matter?

The factor he did not mention is that there are unnamed people who see certain bugs and when they see those bugs, they judge the quality of the software to be poor.

Thus, for human reasons you must fix certain bugs first because it makes certain people feel that the software quality is not poor.

OR because certain bugs prevent the system actually doing what it is meant to do .... thus the bugs that result in the system failing to serve its purpose must be done first.

Human psychology is a thing. If you point a team at a growing pile of bugs that no one has wrapped their head around, then the team will feel demoralized, overwhelmed, and unmotivated. But if someone does wrangle the bug list and produce a plan and strategy for tackling them, then there is hope and mission and maybe you can even get buyin from management for more resources--maybe not headcount, but even just easing the roadmap for a year in pursuit of Quality.

The difference between "nobody has gone through this entire list" and "somebody has gone through this entire list" is huge.

My guess is that the noise of new bug reports was incapacitating the team. You can't fix anything if each few minutes somebody comes to complain about a new problem.

But with the bugs organized he could filter the repeated reports and let people work. As a bonus, he could direct people into solving the largest troublemakers first too, so things get quieter faster.

Quite often what happens in these cases is that people get paralyzed looking at the list of open things, and rather than just digging in and doing something to chip away at the pile, there are meetings and discussions and noise which generates a lot of heat and sound and stress, but doesn't actually make any positive progress towards resolving the issues.

An meanwhile things keep getting thrown on the pile.

The effort to impact ratio is wildly different among bugs in a large backlog. Sometimes a 10-minute single line change will produce a massive benefit for all users. Other times a developer can slog on a bug for weeks only to realize that no one cares about the fix anymore. You want to start tackling the ones in the first category before spending time on the second.

Partly, yeah.

If priority isn't clear, you spend hours on a bug, realize it's minor, realize the fix is difficult...and extrapolate that to the remainder of them. Morale sucks.

If someone can stomach sorting through them, then at least you know you're working on the most important bug at any given time.

It might be investing in tackling it, but I would guess that, more than that, it's that one person was tasked with doing it.

The problem with tedious grind work is, if it's a communal responsibility, then everyone will just sit around waiting for someone else to take care of it.

Some bugs are more important to fix than others. If you rank each bug by effort and impact, you want to fix the high-impact, low-effort bugs first, and the low-impact, high-effort bugs last (if ever).

Reply on news.ycombinator.com