If you solve a bug in a poor way, it might result in even more bugs in the future, so I need a way to validate if the fix was actually good. Time between the bug assignment and issue closed doesn't seem right, so I'm not really sure what metric to use (if there's even one). Measure code complexity after the bug was fixed or similliar metrics don't seem like they relate to the problem at hand. Any ideas?
1To me, it looks that the metric is just a method. But what is the actual purpose of the question / endeavor? Why isn't proper testing good enough? Do you need mathematical proof that the SW is bug free AND that it implements all the desired features properly? The answers are different depending on what you actually need. We might have here a XY problem.– virolinoFeb 16 at 7:30
I'm doing some research into bug tracking systems, and how issues keep being reopened and such. I was just wondering if there was a metric that could measure if a bug fix was good in the first place that I didn't know about since I'm kinda new to this. Hopefully this answers your question :)– ayowhatthedogdoinFeb 16 at 19:30
If your purpose is to reduce the number of bugs, then you need to analyze each bug and see the true cause of that bug. Specifications, testing, implementation... Then you need to "attack" the root causes. So the metric / statistic for this purpose is "the root cause of the bug". There are other potential causes of bugs: teams, people, faulty tools, lack of training...– virolinoFeb 17 at 5:47
If there was a metric to quantify a bugfix, including accounting that "it might result in even more bugs in the future", we would logically be able to use this metric during initial development to ensure we write code that avoids bugs in the first place.
There's a reason why code review is still a human process. There is no universal calculation that tells you exactly what is good/bad and when it is in need of fixing.
Just to highlight one of the many way in which this manifests: Complexity is something we want to avoid but at the same time also a necessary evil, which is why we judge the necessity of complexity based on YAGNI. If you're not going to need it, it shouldn't be there.
How would you expect a metric, which is nothing more than a statistic and/or a calculation, to account for YAGNI? This would require you to somehow input everything you know about the project and its projected future.
Metrics are approximations, and approximations are prone to bias/error.
Time between the bug assignment and issue closed
Just because you solve the issue at hand does not mean you did not introduce another issue.
Measure code complexity after the bug was fixed
How do you know the added complexity wasn't warranted? Maybe the issue was that a part of the logic was too naïve and didn't account for certain edge cases.
Yes exactly. thanks for the feedback, i really wanted someone elses opinion on this. Very grateful! Feb 15 at 23:38
Nice insight: if the compiler could help you, it would have done so already. Mar 15 at 7:30
From a metrics point of view, code changes to fix bugs are in no way different than any other kind of code changes like those for adding a feature or changes for optimizing resource usage.
Metrics look at sucess, failure, time, effort, risk, or certain aspects of code quality. Code changes, regardless whether they are bug fixes or not,
- have always a certain goal (which might be fulfilled, or not, or partially)
- they need always some time and effort
- they have always a certain risk to introduce bugs, and
- they have some influence on the code complexity and quality.
So you could replace the word "bug fix" by "code change" in your question, and would still asking for the same.
Hence, there are no special metrics for rating bug fixes. You can apply any metrics for rating code or code changes. As you surely know, there are several books written about such metrics, there are a lot of tools available, and you find several earlier questions on this site about metrics for code quality, which can equally applied to code changes for bugfixes or code changes for any other reasons.
However, if those metrics are really useful is a different question, very debatable and opinionated. It depends mainly on your goals and expectations - and from the comment under your question, it is pretty obvious you haven't clarified those goals yet. You may start here What are useful metrics for source code?. But what I really recommend is to look at the classic WTF/m metric. Though the last one was intended to be a joke, it is probably the only one which really matters - the assessment of a code change (might be a bug fix) during a code review by a human.
Code quality assessment requires human eyeballs.
In other words, use code review by your peers (those who might be the ones to fix this code later) to evaluate if you wrote good or bad code to fix a bug. Github and similar provide pull requests to relatively easily see your changes. Good IDE's support it natively (unfortunately too few).
So, get criticism, revise accordingly and repeat until your peers are satisfied.