3 ms·

Neither in the article or in the referenced article/blog post linked to "Impact" is impact defined. https://blog.gitprime.com/impact-a-better-way-to-measure-co

Neither in the article or in the referenced article/blog post linked to "Impact" is impact defined. https://blog.gitprime.com/impact-a-better-way-to-measure-codebase-change 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.

debaserab2 10y ago
Not to mention that's a pretty easy to game metric. By that rational, renaming a variable name across a few files is going to make me quite impactful. If my job were being judged by this metric, I'd sure be thinking a lot about that. This measurement also seems to favor overengineering, which is one of the biggest things I've learned to stay away from. When I was early on in my career, I thought I could implement anything myself, and so I often did. It wasn't until years later that I understand the implications of maintaining these implementations. A true measure of impact to me would be a ratio of the most concise (but still understandable) amount of code to the amount that it solves the requirement it's built for. It's impossible to measure that without the context of the problem you are trying to solve.

debaserab2 10y ago

Not to mention that's a pretty easy to game metric. By that rational, renaming a variable name across a few files is going to make me quite impactful. If my job were being judged by this metric, I'd sure be thinking a lot about that. This measurement also seems to favor overengineering, which is one of the biggest things I've learned to stay away from. When I was early on in my career, I thought I could implement anything myself, and so I often did. It wasn't until years later that I understand the implications of maintaining these implementations. A true measure of impact to me would be a ratio of the most concise (but still understandable) amount of code to the amount that it solves the requirement it's built for. It's impossible to measure that without the context of the problem you are trying to solve.