Code Longevity Tracing

What is the benefit of looking at code longevity?

Code longevity metrics give you clear visibility into several code quality problems that other metrics don't.

First, when code is removed or replaced within a few weeks, this means that it failed to meet requirements at best, and more likely suffered from severe bugs. The benefit of code longevity over traditional metrics like bug counts is it shows you which original change caused the problems so you can do a better job of preventing quality issues in the future.

Over a longer time frame, code longevity can highlight poor code quality by identifying code that had to be removed or refactored several months down the road vs. code that reached its full expected lifetime.

Finally, code longevity can pinpoint code that has been abandoned and is no longer maintained by identifying unusually low amounts of code replacement.

How do you determine when a line of code is removed or replaced?

For every new commit, minware's code longevity tracing system looks at when each removed or replaced line of code was originally written using a method similar to Git blame. It then associates the removals with the original commit that added each line and aggregates them so that you can see how many code lines are still surviving at each point in the future.

Does code longevity require full access to my source code?

minware's code longevity system does not actually look at the original code. Instead, it computes a hash of each line so that it can tell which lines are the same, but it does not store the code itself. However, minware's initial ingest step does temporarily read the original code to produce the hashes, though the code is not stored anywhere in minware's systems.

Does code longevity work across file renames?

Yes, minware's code longevity tracing system will detect when a file has been renamed and treat it like it is part of a single file history the same way that Git blame is able to handle file renames.

Does code longevity work across squashes and rebases?

Yes, unlike Git blame, minware's code longevity system will trace changes back to their original commits through squashes and rebases so that their longevity timeline doesn't end at the point of a squash or rebase.

How else is code longevity tracing different from Git blame?

(Nerd alert, this is a bit in the weeds.) The problem with Git blame and the reason we created our own system and submitted it for a patent is that Git blame uses a backward-looking algorithm that is unstable as you add new changes. That is, the Git blame for a commit B that comes right after commit A may be vastly different from commit A's blame as compared to the changes in commit B. This makes it unreliable for code longevity because code can disappear without actually being removed or come back after an earlier commit shows that it is gone.

minware's code longevity tracing algorithm maintains a mapping of when each line was written and incrementally updates that mapping with the same changes that are in each commit for guaranteed accuracy and stability of metrics over time (i.e., new commits will never affect past removals).