33

It's obvious why you should track ongoing bugs. It's not at all obvious to me why you should track solved bugs. If a bug is solved, then just email the person who submitted it, delete the bug once they're happy, and maybe give your boss a thumbs up. Despite this, every bug-tracking guide I've seen suggests to track whether or not a bug is solved. For example, point #4 here suggests it.

So, what are the benefits of retaining a record of solved bugs? Is this standard practice? If so, why?

5
  • 48
    "Hey, you only did 8 days of feature work this past month. I see nothing else in our logs so I can only assume you've been slacking off for the other 12 days."
    – Flater
    Mar 15 at 23:44
  • 37
    In all bug or issue trackers I have seen, marking an issue as solved and keeping it in the database does not cause any more effort than deleting the record - quite the opposite. If I want to see just unresolved issues, that's easy and usually the default view. Storage for keeping resolved bugs and their reports is so minimal compared the other artifacts in any reasonable project that keeping them or not does not make any difference. Hence, keeping solved bugs is a no-brainer - so could you tell us what benefits you expect to find in not keeping them?
    – Doc Brown
    Mar 16 at 11:57
  • We track the four quadrants our issues fall in: Bug, Feature, Tech debt, New Architecture & we track the percentage of time spent per sprint on these quadrants. By upping Tech debt spending we aim to reduce Bug spending
    – Tvde1
    Mar 16 at 13:09
  • 3
    Why should tracking a bug be fundamentally different to tracking any other type of work?
    – James Wood
    Mar 16 at 14:02
  • What are reasons not to keep it around? Disk space is pretty cheap
    – Helena
    Mar 16 at 21:23

12 Answers 12

86

In addition to Thomas' answer, a bug report that leads to a code change is just as much a part of your code's history as the requirements specifications, architecture documents, customer change requests, etc.

Another way to look at it - would you delete the requirements documentation after having successfully implemented a feature in the code, or would you leave these so that you (or other developers in future) have some chance at being able to discover why the code exists and are able to validate that the code actually does what its users/stakeholders have asked for?

Ideally a bug report will contain a lot of valuable information for future developers digging into the code to learn when and why a particular line might have changed. For example - Who reported the bug and when; The circumstances around the bug; How to reproduce it; Root-cause analysis; Some discussion with stakeholders on the validity of the bug; along with any other potentially relevant context.

As far as standard practice is concerned, I would also expect developers raising a pull/merge request for a bug to explicitly reference the ID of the bug in their commit message(s) and/or the PR itself so that the source control history also provides breadcrumbs to the bug database.

Future developers having the source/commit history can use this to relate individual lines of code back to the original thought processes and reasoning behind why that code had been changed by following breadcrumbs like a Bug ID.

Otherwise if the bug report is deleted then all the valuable investigation, discussion, analysis and reasoning is lost along with it.

9
  • 22
    I'd add that having the bug report log can be useful even for senior developers, or junior developers that have been around since the bug was first introduced, if it pops up elsewhere in some other form - "Oh, I remember seeing that before - hang on, let me look up where it was, and how we fixed it there. Ah, right; we'll want to check how we use <X>, if we use it, because misuse of it in <Y> caused it in the previous instance a while back.". Mar 16 at 5:13
  • 23
    Not to mention that bugs often come back since they weren't actually truly solved. When there's a problem with the bugfix (effectively "the new feature"), you want access to the original thinking process, the guy who made the fix etc. I wouldn't be surprised if most bugs actually came from fixes to other bugs - it's very valuable to track these relationships, especially when your management doesn't really understand software. I've gone through many teams where we looked slow on the surface (these guys fix 3x more bugs than you!) but actually we just caused fewer bugs in the first place.
    – Luaan
    Mar 16 at 9:01
  • 5
    I'd say that looking at solved bug reports has kept me from refactoring that weird bit of code that fixes the bug, but that looks clunky, on several occasions. Or, if I do make the changes, helps me figure out why I broke it.
    – lupe
    Mar 16 at 10:02
  • 4
    @lupe: solved bug reports are definitely of high value, but when weird code is needed to prevent a wrong behaviour, then I think there should be a comment in the code. Without such a comment, I would usually not have to idea to go through the list of the latest 500 solved issues to find one which is related to the specific code construct. Of course, the comment could refer just to the bug ID in the issue tracker, but actually I prefer a small clear-text explanation so I don't have to lookup it elsewhere.
    – Doc Brown
    Mar 16 at 12:05
  • 9
    So true: If you do not keep history you are doomed to repeat it. If you forget solved bugs you are doomed to reintroduce them. I has experience of using 5+ year old bug reports in conjunction with source control history to understand the reason behind a piece of code and refactor it to satisfy new requirements, while preserving old one. I am so annoyed by junior developer's desire to squash history and delete bugs.
    – jhnlmn
    Mar 16 at 17:08
51

In addition to the other answers, the practicalities of software production process also influence this:

  1. Bug fixes are usually not immediately put into production. Often it can be weeks or months before the new version reaches every user. In the meanwhile, the bug can get reported multiple times, so it is important to be able to quickly find it, determine that it is the same issue and that a fix has already been made.

  2. Bug fixes are not always correct on the first try, or they can introduce new problems. Then you need to rework the bug fix, and it is important to have all information available on how it was originally detected and tested for.

1
  • 3
    On the "not immediately put into production" aspect: I work for a company that makes Windows software, both desktop and server-based. Our customers deploy a new version only carefully, typically every 3 years. Our support duration is about 3-4 years. If a customer comes to us with a bug report for their version from 2021, we can find that it was resolved in a subsequent version from 2022, and then we can (a) advise the customer to upgrade and/or (b) decide to retrofit the fix in the branch they're using. But we couldn't do that if the bug-fix information from 2022 had been erased.
    – Nimloth
    Mar 17 at 13:23
36

It depends on what you're going to do with the data. There are plenty of things that you can do if you keep track of resolved issues.

From a product quality perspective, you can keep track of regressions or reintroduced issues. If you've fixed a bug once, fix it, and then get reports of the same issue occurring again, you may have introduced a regression. Understanding when and why you're introducing regressions can help you to prevent them.

You can also keep track of metrics like the source of reports to determine if issues are being found internally or externally, how frequently new issues are being reported, or how long it takes to resolve an issue once one is reported. These can be useful process quality metrics.

Not all organizations will need or want to take advantage of this data. But using an electronic defect tracking tool and having otherwise good habits around recording issues and appropriate metadata would make it easier to do analytics in the future should you want to.

18
  1. Traceability - your code change is linked to a bug report, making it clear why it was done. Ideally, the bug report is linked to whatever requirement was not met or the test specification of the test that was red

  2. You want to be able to reliably answer the question "was the bug fixed?" a few weeks from now. Ideally, by pointing at the change and also a green test case

  3. Similar bugs found in other projects can benefit from your solution

  4. Your SW will be out for testing in different versions, and you will get bug reports for older SW - it's good to know a bug is known, and fixed, in newer versions so you don't waste time.

  5. When a regression happens, you will have an easier time identifying where in the code something broke. Could be a bad merge, or a new change, but regressions happen from time to time.

0
14

Often there is a good reason for a code change, as shown by the bug report, but a year later the reason is forgotten. Someone spots the bug fix code, thinks it is unnecessary complicated, and removes it. Then comes a new bug report and this repeats.

Having fixed bug reports available may help preventing this. (Although adding comments why your code does something unusual should work better).

13
  • 4
    This is so important! If the code that fixes the bug is somewhat counterintuitive, I'll often write a comment like "We need to foo the bar here, see bugtracker #1234". It doesn't make sense to copy all of the bug report into a code comment, but I do want to be able to understand the reason for that extra code in a year or 5. Mar 16 at 15:41
  • 1
    +1. Another variation is that a compiler will sometimes make an incorrect "optimization", so the transform gets disabled in cases that cannot be proven sound. Someone else notices the compiler isn't performing the optimization in cases where it would be useful and "fixes" it so it will perform the transform in those cases (but also in the erroneous ones).
    – supercat
    Mar 16 at 16:03
  • 2
    Hopefully, a test was implemented that ensures this bug is fixed, and after the audacious programmer simplifying the code removed the bugfix this test fails, before the newly faulty code goes into production and annoys the customers enough to file a bug report, or shuts the powerplant down. Mar 17 at 2:42
  • 2
    @supercat 98% of these cases are caused by buggy code and a programmer who insists they are never wrong and the compiler must be wrong.
    – user253751
    Mar 17 at 14:36
  • 1
    @supercat are you talking about this bug? gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 there seems to be consensus that such pointers may compare equal but are not actually the same pointer; the comparison is not undefined behavior, but the outcome is unspecified (uncertain); the pointers are not the same, even if they compare equal, so dereferencing the one-past-the-end pointer is undefined behaviour. In fact two pointers may contain the exact same 1s and 0s and yet dereferencing one is undefined but not the other. If your code even cares about these dark corners of C, it's wrong.
    – user253751
    Mar 17 at 14:56
13

Aside from everything else that’s been mentioned, having a list of resolved bugs since the last release of the software is actually kind of critical for being able to write good release notes. Users expect to see a list of what was fixed, and if you don’t keep track of what was fixed, the best you can do is something really vague like ‘Numerous bug fixes’.

This specific aspect obviously does not matter as much if you’re using a continuous-delivery model without user-facing versions, but there’s a lot less software using such a release model than there is that uses a traditional fixed release model.

8

Another reason is to track what ”areas” (being deliberately vague here, but excluding blaming people or micromanagement as a valid motivation) of your codebase introduce the most bugs.

For example, we once had a longstanding small-ish feature that was involved in 40% of our team’s customer-identified bugs.

This type of hotspot may have architectural issues or excess technical debt needing to be addressed at some point.

Likewise I once met someone who had had a fast track promotion from a beginner tester in a videogame company by having the insight to apply statistics to show which GPU families were most involved in which bug classes thus allowing better prioritization.

As another example, you may want to look at browser releases involved in server side errors in order to determine any recurring patterns.

These are concerns that outlive any particular bug.

5

In addition to the excellent answers given already, another reason to consider keeping the resolved bug/issue reports would be that the organization you're working for may have audit requirements for the SDLC, especially, if you're in a highly regulated environment.

4

In any work for pay it can also be used for time tracking and resourcing.

If you do the work you track the work so the boss knows it's been done and about how long it took.

If you don't do this you risk a project with time allocated only for new features and anyone who isn't adding them looking like dead weight.

3

Fundamentally, if you are tracking ongoing bugs then you have entries in a record. You do not just remove existing entries from a record because you think it isn't useful anymore. That defeats the very purpose of having a record and is fundamentally bad practice. Records exist because you never know when or why you might need the info in the future. You simply do not go around selectively removing entries. Imagine if a doctor erased the fact someone had cancer from their medical history after they were successfully treated. After all, the problem is solved, right?

You should not need a reason other than this. It doesn't matter if you can't foresee any benefits to tracking resolved bugs because the fact is that the ongoing bug reports already exist and you should not be removing them from the record. Since records should not be left hanging, at minimum, when something is no longer being updated it should be recorded as such. It just so happens a resolved bug report is equivalent to that.

Frankly, an entry saying that the status of a bug will no longer be tracked without stating whether not it was actually fixed, whether or not it will ever be fixed, is more acceptable than going around wiping resolved bugs from the record.

2

This was only mentioned as an aside in other answers, but:

You implement a test verifying that the bug is gone, with a link to the original bug description, analysis and solution. That test becomes a permanent part of the test suite.

Some bugs can re-occur. As a trivial but real-world example, a poor architecture demands that when you change x you also have to manually change y (there is no automatism for it); the next time somebody changes x without reading the documentation the test fails before the error is shipped. Then it is nice if there is documentation what the test was for, what the root cause is and how to fix it. This is most valuable if a bug like memory corruption manifests only sporadically in unpredictable ways but its cause can be reliably pin-pointed by the test (which e.g. verifies a buffer size).

-2

In my opinion, the other answers provide a lot of good information, but they do not directly answer the question.

What are the benefits of tracking solved bugs?

One of the definitions of 'to track" in the Merriam-Webster dictionary is:

to observe or plot the moving path of (something, such as a spacecraft or missile) often instrumentally

Obviously, solved bugs do NOT have any path and any change.

However, they carry a lot of information with them (see the other answers) so they are used for all kinds of statistics, for all kinds of purposes. Mainly, they are used to see the work done in the past, and to see how new work progresses (or regresses) compared to older work.

These statistics are invaluable for tuning the advance of the project.

Those who fail to learn from the mistakes of their predecessors are destined to repeat them.

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