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