I've never understood why bugs get treated differently from new features. If there was a bug, the old feature was never completed. The time cost and benefits should be considered equally.
Yet engineers are pushed to give unknowable estimates of points and when things take "longer" (did you notice that shift right there?) they are either overdue, taking too long, or they don't, and to say: "It takes as long as it takes." is not accepted by middle management.
That's a strawman. It is not really related to the main point and I'm not sure of the point you're trying to make (maybe that tension exists?)
Obviously things take as long as they take. I've always been an educator of this back to the business leadership. In my experience, most business people truly have no freaking clue how a product gets built and code gets shipped.
Giving proactive updates (meaning not the day it was expected to be done according to last update) are important part of a professionals working life. There's always a tension between business and engineers. Engineers just generally don't do that well with tension and try to minimize it, or complain about it.
I read them as agreeing with you, but pointing out that fixing bugs, at the end of the day, is up to the client.
It's just a predictable dance. You say something will take this long, then you find a bug. You point it out to the client, and they get mad at you because your estimate was off. They try to pressure you into fixing the bug for free, whether you were even around when it was made.
Eventually you just make a judgement call about bugs every time you run into them.
Because the goal of most businesses is not to create complete features. There's only actions in response to the repeated question of "which next action do we think will lead us to the most money"?
