When it comes to software developers' time spent on bug fixes you would think there would be some truisms in computer science. Unfortunately, there aren't many. Even a cursory dive into the subject raises more questions than answers.

Two solid articles here say 75% of developer time or 25% of developer time is spent debugging. Are we talking about fixing bugs after system testing, during unit testing or even debugging while writing code? Can you accurately predict how long a fix will take before doing it? Is it worth even trying to estimate?

But I'm going to try to give more answers (or at least my opinions) than questions in this post.


Estimating In General

If you asked me (and you're here reading this, so I guess you did), the ability to estimate hours on projects is one of the primary skills that veteran programmers do better than young programmers. It's somewhat of a vague art and you just get better at this over time.

Personally, I've kind of settled on this process for estimating whole projects: 1) Blocking out what I think the time will take for all tasks, 2) If requirements or instructions are vague, add 30% of extra time to the project, 3) If you've had a good working relationship with the people involved then add nothing, if previous work with them has hit a snag then add another 15%, 4) If you think there will be lots of meetings with 5 or more people, add another 10%, and 5) Whatever figure you now have, add another 25%.

Basically, however long you think something takes, add 40% more time.

The rest of this article, when referring to estimating, is more about quotes for bug fixing time and not for general, new, "greenfield" development.


Too Long or Too Short, That Is The Question

I think we all can see the merits of erring on the side of overestimating than underestimating. It's not just setting the bar relatively low so the project can exceed expectations - although that's a part of it.

Whether it's an internal estimate for a manager or more formal estimate for a client, EVERYBODY in the project looks better when things are ahead of schedule (and under budget). Setting at least reasonable expectations is always better. Resist the temptation to say what you think your client or manager wants and instead say what you think really will happen.


2 Hours or 2 Days

Despite what I just said about good developers being better at predicting what will happen, programming is still hard and it's unpredictable. If somebody tells you they know exactly how long a new problem will take to fix, let me tell you this plainly: they are lying.

The actual answer to the question "How long will this take to fix?" is a frustrating one. It's usually something like "Either 2 hours or 2 days, I really don't know." That’s frequently the truth and it really doesn't help anybody (the developer, other developers on his/her team, his/her supervisor, management, clients, etc.) to answer "I don’t know."


Being Fair To Management / Clients

What I just said above is with my developer hat on. I can get irascible when asked about bug fix time because in my surly programmer head I'm thinking "They have no idea how programming works, they don't get it." Software designers can be catty, defensive or arrogant (or all 3 at once). And I include myself in that statement.

But let's put my manager hat back on. If I ask a programmer how long he/she thinks it's going to take, I need SOME answer. I'm not going to roast them later if they’re off, even significantly. But the programmer should have some insight to the issue: Will the change be in a part of code that was already thorny and troubled, or will it involve changing a couple of values in a configuration file?

My advice to programmers: When you get asked for a fix estimate, take a deep breath, don't send that pissy email, and do your best and give a range of what you think (e.g. "If we get lucky, 3 hours, if it's worse, then maybe 15?").

My advice to managers/clients: When asking for a fix estimate, remind the developer that it's an estimate and even a range of best case - worst case will help.

(If you're interesting in reading more of this in what I think is a very solid article, take a look at this: https://blog.professorbeekums.com/estimating-software-bugs)


Prioritizing - Should The Bug Even Be Fixed (Right Away)?

Once you have a guess at how long it will take, then everybody (developer and manager/client) needs to decide if the bug is worth fixing, or where to put on your QA/debugging list.

I was always taught that there are two metrics for bug triage: 1) How vital of a fix is it, and 2) How easy is it to fix. This is commonplace and common sense. If something is easy and important, then do that right away. Then triage the easy typos and tough deal-breaker problems in a mix in the middle, and kick those minor but hard problems down to the bottom of the list.

(Extra reading for those interested, more solid thoughts about bug-fix triage: https://www.chromium.org/for-testers/bug-reporting-guidelines/triage-best-practices)


Should You Try To Estimate These

I'd say you should almost always try to do some broad-stroke estimates on how long things will take to fix.

The only exceptions for me would be 1) When there is such a level of trust between manager/client and developer that we always know the developer is going as fast as he/she can, or 2) When the bug is so small, like a typo, that even typing out the question "How long will that take?" is a waste of time.


Takeaway - Communicate

My main takeaway is that manager and developer need to be fair and patient with each other. Trust each other that you're on the same team and give a range of expected fix times.

Managers: Understand that the developer probably is more qualified to know this than you, so when the developer gives you the estimate, then live with it (unless prior track record on this front is poor). And if the programmer missed the predicted deadline, don't try to catch them in a big "Aha!" moment.

Programmers: Yes, it's hard to predict. But your manager is not an idiot who's out to get you. Your manager needs to know and also needs to probably tell THEIR manager. Do your best and if things are running long then communicate that in advance.