Bug pops up. A critical one. How often does this happen to you?
I have to stop whatever I’m doing because a customer can’t use the product.
I read the bug description on Redmine and think of reasons why the code broke. I eventually reproduce the error and I ask around which developer can fix the issue. We work together to isolate the issue, test the patch in staging. We ship the code and the clock says time to take the train home. An entire day is gone.
That’s the idea scenario if we diagnose the issue correctly on the first attempt. Quite often we’ll discover another problem the fix didn’t completely address. Whenever I commit to fixing an issue, I always remember –
Every bug fix will drain at least one developer’s day.
I can’t spend all my team’s time fixing bugs. And if we don’t fix them, then the product becomes unstable. I often wonder, “What is the ratio of fixing production-breaking bugs to development time?”
I may intuitively realize we spend too much time fixing issues. I would track this ratio on a month-to-month basis as a warning metric. On a monthly scale, I’ve been in situations where it’s 1:1 (50% of time is spent bug fixing and 50% of time is spent creating new features.) During the early days of a startup I find the ratio is close to 0:1 and we’re flying by writing code. I’ve also been in bad situations of 1:0 where we spend all of our time fixing issues.
I check we’re not constantly fixing bugs and switching back to development. I can’t speak for everyone, but I find bug repair draining. If I spend an entire day chasing down and fixing an issue, I’ll have a difficult time switching back to development. I would imagine morale and productivity dropping if an engineer is jumping back and forth from fixing to creating 5 times in a week.
I can’t avoid bugs. The key is I don’t have my team fix all of them. The cost to track one down, fix it takes up far more resources than I ever plan for.
I would carefully examine the percentage of bug fixing to feature development. Either extreme is no good. 50/50 is realistic. (Half your time is spent fixing problems created from the past.) Perpetual bug fixing won’t ever advance your product, and pure feature development will eventually get you when all bugs creep up.
For your team, this means half your team will be fighting fires. The other half will be building. If that’s the state you’re in, that’s the outcome of how you allocate team resources in the beginning. One of the toughest things in engineering management is how long your decisions play out.
Leave a Reply