[hiatus]

> You need to take the time to understand why the bug happened, or you’re just going to be patching wallpaper instead of fixing the plumbing leak.

I think many would like to probe deeper but aren't afforded the time between sprint tasks. Management often pushes back for solutions that are good enough compared to exploration with an unknown duration until the solution is found.

[default-kramer]

Of course this can vary wildly, but I've never felt afraid to defy management on that one. Half the time, they don't even need to know. And the other half of the time... what are they going to do? Fire me? Fine, then their project will be filled with nothing but wallpaper-patchers and I'll be somewhere else doing good work.

(And of course, sometimes just patching the wallpaper is the right course of action, but it's rare to find management capable of accurately assessing this trade-off.)

[8n4vidtmkvmk]

Yeah, at a certain point I just stop caring what management thinks and just doing what I think is right. I usually don't get the recognition I think I deserve for preventing future issues but no one complains either.

[__turbobrew__]

Part of being senior is figuring out how to work in those constraints. In that situation I would push back my manager and tell them why root causing bugs will save us time in the long run and if they still don’t relent I would sandbag some of my time doing sprint tasks to root cause the bugs.

[ohthehugemanate]

Which is why it's so important for teams to agree with management on a definition of "done" well in advance, to avoid this kind of argument later. Also why it's important for management to understand that velocity/estimation are Descriptive for long term planning, not Proscriptive and short term.