Can you consider a bug fixed when the underlying cause was not fixed?

by Timo Türschmann   Last Updated January 22, 2018 17:05 PM

Let's say there is an extensible system in place, which uses an algorithm that requires that the elements it operates on are unique.

The signature to call this algorithm looks like this: function algorithm([List of Elements])

Now there are multiple modules that use this algorithm, which call the algorithm like this:

[List of Elements] elements = [...]
[make sure the List only has unique elements]
algorithm(elements)

Say, there is a new module added which looks like this:

[List of Elements] elements = [...]
algorithm(elements)

(i.e. it doesn't make sure that elements are unique).

Now, in a majority of cases all elements are unique. But once in a while an Exception is raised by the algorithm complaining about the duplicate elements.

This exception is reported as a bug and should be fixed.

Now, would the bug be "fixed" by simply adding [make sure the List only has unique elements] to the offending module [Fix #1]? Or would the bug be fixed by changing the signature of the algorithm to function algorithm([Set of Elements]), so that the bug that's fixed is impossible to reoccur with any future modules [Fix #2]?

I'm specifically asking about this coming up in a review - should the bug fix be "done" if you review Fix #1? Should the changes of Fix #2 be added as a new refactor task? Should Fix #1 be rejected until it is implemented like Fix #2?



Answers 1


Both are fixes to the bug; they both remove or prevent the situation causing the problem from occurring again.

Fix #1 is possibly a bit short-sighted, as there may very well be another situation where a new module is added and the developer forgets / doesn't know about the check for uniqueness. Fix #2 solves that potential future problem by making it impossible for the elements to not be unique, but comes at a cost of refactoring the existing modules to accept the new signature. The amount of refactoring may be small or it may be large, we don't know (but hopefully you at least have an idea), and that may dictate whether you want to implement fix #1 or #2.

mmathis
mmathis
January 22, 2018 16:53 PM

Related Questions


Good cross-check metrics for software quality!

Updated February 17, 2017 12:05 PM

GitHub - Should I unassign an issue once closed

Updated July 17, 2017 15:05 PM

Tool to Map / Track (visually) Functions usage

Updated April 16, 2018 22:05 PM

Using commit messages for time tracking

Updated May 03, 2018 02:05 AM