2

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?

Improve this question
3
  • 1
    To 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.
    – virolino
    Feb 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 :)
    – ayowhatthedogdoin
    Feb 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...
    – virolino
    Feb 17 at 5:47

3 Answers 3

Reset to default
10

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.

Improve this answer
2
  • Yes exactly. thanks for the feedback, i really wanted someone elses opinion on this. Very grateful!
    – ayowhatthedogdoin
    Feb 15 at 23:38
  • Nice insight: if the compiler could help you, it would have done so already.
    – Thorbjørn Ravn Andersen
    Mar 15 at 7:30
3

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.

Improve this answer
2

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.