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?

> 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'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.