I feel like many bugs in the wild just come from business processes slowing everything down, especially in larger companies. It might seem like a bug that can be fixed in half an hour, if anyone spotted it, but instead:
they need to file a ticket
it gets discussed in planning, but postponed because there’s an extremely important™ deadline (repeat this step like 5 times)
someone from upper management notices the problem and sends an angry mail; it is finally included into the sprint
they implement the change
it gets rejected in code review due to some nitpick
they fix that nitpick
it passes code review and is merged onto main
it gets discussed again in sprint review
it gets shipped two months later
ah crap, something broke; need to bisect a few hundred commits to find out it was this change that broke it
spend half a day preparing and testing a hotfix release, because the next proper release is months away
it gets rejected in code review due to some nitpick
…you get the idea.
You go through that slew of bullshit exactly once before you learn to turn a blind eye to anything that looks easy to fix.
So Ephera, why is this bugfix taking more than 1 hour?!!
Bugs are not possible to evaluate (except the most simple ones) and if you can’t completely fix the bug and its deoendency bugs in the original time allocated then everyone will think you just wasted time. Or so it has been for me on those “Agile” jobs.
Yeah, I didn’t even include technical debt into my list, but it comes up so often as well. Chances are someone else already saw the problem, considered fixing it, then saw the mountain of technical debt blocking a fix, and decided to ignore the problem in the end.
For me, thankfully, folks have been understanding so far, when a bug fix takes significantly longer than expected.
But we also explicitly don’t estimate bug fixes upfront, because of what you say. You have to diagnose the bug to figure out what solution is required. And the solution can range from a one-line-change to a refactoring of half the codebase. Good luck estimating that…
I feel like many bugs in the wild just come from business processes slowing everything down, especially in larger companies. It might seem like a bug that can be fixed in half an hour, if anyone spotted it, but instead:
mainYou go through that slew of bullshit exactly once before you learn to turn a blind eye to anything that looks easy to fix.
So Ephera, why is this bugfix taking more than 1 hour?!!
Bugs are not possible to evaluate (except the most simple ones) and if you can’t completely fix the bug and its deoendency bugs in the original time allocated then everyone will think you just wasted time. Or so it has been for me on those “Agile” jobs.
Yeah, I didn’t even include technical debt into my list, but it comes up so often as well. Chances are someone else already saw the problem, considered fixing it, then saw the mountain of technical debt blocking a fix, and decided to ignore the problem in the end.
For me, thankfully, folks have been understanding so far, when a bug fix takes significantly longer than expected.
But we also explicitly don’t estimate bug fixes upfront, because of what you say. You have to diagnose the bug to figure out what solution is required. And the solution can range from a one-line-change to a refactoring of half the codebase. Good luck estimating that…