Hacker News Reader

Comment by edoceo | Hacker News Reader

This is dumb. Bugs have costs. Costs to exist and costs to fix.

Eg: my software has a bug, with a workaround that only affects 20% of my clients, once a month. This bug costs $20 each occurrence. So call this a $400/mo bug.

But we've got other bugs are $4000/mo bugs. Or $6k OTC bugs.

And we know what our dev time costs.

So, stop gaming devs against a broken guessing game.

Use real numbers, if you care about your code. This bug costs $400/mo to exist - spend $4000 of your dev time to fix it.

It's not: can you fix in time-guess for points - that depreciate over time (reducing motivation)

It should be: managers will leave you alone for 16h so you can work this one problem to death. Devs can then finish their tasks and gain confidence and pride.

Gaming devs against each other is not a good long term strategy. Measure the priority and allocate resources from that.

View on HN

> This bug costs $20 each occurrence.

Knowing how much a bug costs is not always trivial.

I would argue that figuring out the real cost of a bug is not trivial most of the time.

Well, you know how much time costs right? And you know how much time each client waste when the bug occurs? If you don't then fix that. These are values that can be measured from real world, empirical.

Guessing how long to fix, or how many "points" a bug will take is complete BS next to real-world values.

Why make devs guess at the future when you could have business manages measure the present?

I'm not sure client's time wasted is the right way to measure. For example, I would prioritize a high-risk security related bug (regardless of its effect on my systems performance) over a memory leak.

Right! And my point is that it's easier to measure present cost of $THING. And to compare to other so-measured things than it is to guess at time to fix. You can assign some cost to that security thing can't you? You can assign a risk and then assign cost to that risk.

I never stated that client time was the thing to measure. I'm saying (now repeating) that PRESENT COST is a better basis than FUTURE TIME GUESS.

The whole problem is management wants to maximize dev-time so they try to cram bugs to make your time full - based on a guess. It's ass backwards.

Measure the problem then budget resources to fix.

> Guessing how long to fix, or how many "points" a bug will take is complete BS next to real-world values.

The difficulty is that "how long to fix" literally has to be a guess. Even with up front investment to investigate the nature of the bug and how to go about fixing it, the end result is still a guess, just a more educated guess.

Unless you're exceptionally good at predicting the future. We should have a sidebar chat if this applies to you.

I've played this game before, but it ends up being really difficult to estimate the cost of a bug. E.g. what's the cost of not upgrading <libraryX> from v1.2.0 to v1.5.0? Or a theoretical security bug that you think is going to be quite hard to hit, but would be ruinous if it was exploited? Is that bug 0.001% or 0.01% likely to be triggered?

In practice it's impossible to get accurate ROI estimates for large chunks of the work you do. So being honest about that and using an approximation often doesn't cost you any appreciable accuracy -- and you will definitely spend less time trying to figure out how to precisely cost your bugs.

Don't get me wrong, I'm in favour of using ROI as a lens for prioritizing bugs, I've just never seen anyone make a credible estimate that's more accurate than the nearest order-of-magnitude.

I'm sure this is much easier the bigger you get; Google can estimate how many clicks are lost due to a bug, and clicks are of known value, so you can make a case for this bug being worth $Xm. But for startups I think this is unfeasible because you're working with such small sample sizes.

Reply on news.ycombinator.com