https://blog.gitprime.com/impact-a-better-way-to-measure-cod...
What I found is:
Impact takes the following into account: The amount of code in the change
What percentage of the work is edits to old code
The surface area of the change (think ‘number of edit locations’)
The number of files affected
The severity of changes when old code is modified
How this change compares to others from the project history
No exact or detailed formula for "impact" is given. "takes the following into account" is extremely vague as it could indicate any relationship. Is impact higher with more files changed in the commit? Why would it be better if more files are changed? Is it lower? Why would it be better if fewer files are changed? Is it some totally unobvious non-linear function such as a trigonometric sine?Based on the vague description above, nothing in "impact" is directly related to the actual end user/paying customer experience or a reasonable proxy such as systematic end user testing by a QA team.
This lack of a direct relationship to the desired end result is the same problem that lines of code (loc or LoC) and many other metrics of software engineer output have.
The "impact" metric, whatever it precisely is, looks suspiciously like it would naturally be positively correlated with a large number of commits/high frequency of commits.
Also the plot is labeled with "volume" on the horizontal axis and not the mysterious "impact" metric. The text implies this horizontal axis is the "impact" metric. Why is the horizontal axis not labeled impact?
Even more peculiar, "impact" is claimed to measure cognitive load:
Impact attempts to answer the question: “Roughly how much cognitive load did the engineer carry when implementing these changes?”
A good engineer will attempt to find a low or no cognitive load solution to a problem! In general this will be faster and less error prone and cheaper! Reinventing the wheel has a very high cognitive load.