Software bugs are an inevitable part of any complex application. The human mind may be able to understand how an application works at a high level, but being able to have every detail floating around in your head is impossible. That means that it is very easy for a programmer to miss handling a specific situation in their code, aka edge cases, because they aren’t thinking about it.
The result is unintended behaviour in that software or a software bug. Since bugs are unintended, it is hard to say how long it will take to fix them.
In order to provide an estimate, you need to know what has to be done to fix it.
In order to know what has to be done to fix the bug, you need to know what is causing the bug.
In order to know what is causing the bug, you have to investigate the cause of the bug.
Because the bug is unintended, you usually won’t know the cause of the bug right away. You will have to spend time to investigate it. More often than not, the investigation will take the largest amount of time. By the time you know enough to estimate a fix for a bug, you’ve done most of the work to fix it.
This is challenging from a project management perspective because the goal is to maximize return on investment for the company. Developers are extremely valuable and their time needs to be spent well. To calculate ROI for fixing a bug, you need to know how much value fixing the bug will bring to the business and how much time it will take to fix.
Determining the value of fixing a bug isn’t usually too challenging (though it is a bit of guesswork sometimes). The other half of that equation is a different story for all the reasons listed above.
The funny thing is: software developers make estimates for software bugs all the time.
How long would it take to fix a typo? Probably not much.
Is the bug a bad math calculation that can be reproduced 100% of the time and is in an area covered by unit tests? That probably won’t take too long to fix.
Is the bug something that can’t be reproduced on a developer’s machine? That will probably take a while.
None of these are estimates in the form of “2 hours” or “2 days”. They’re going to be more fuzzy such as “should be quick” or “may be tricky”. But it’s not like the value of fixing a bug is going to be an exact dollar amount either. A rough guess is better than nothing. If you have a suspicion that a bug few users will ever see may take days or weeks, then it’s probably not worthwhile to fix.
The problem is that developers don’t like communicating these estimates and for a good reason. The estimates are gut feelings and have a high probability of being wrong. Even something as simple as a typo can take a while if the system is poorly built (e.g. the code is in a database that the developer does not have write access to). Whether it’s a justified feeling or not, developers don’t want to give out an estimate that has a high chance of being wrong because they may feel that their manager will treat it like a promise.
Regardless of whether managers actually do that or not, the feeling that they would is counterproductive. As mentioned, a rough estimate is better than no estimate. Any communication is better than no communication. The way to get estimates on software bugs is to make developers feel comfortable communicating the thoughts they already have.
This post was originally published on blog.professorbeekums.com
Top comments (0)