GitClear started building the Line Impact metric in 2016. In its baby pictures, it can be seen teething on duplicate committers and commits. In the past three years, the metric has scaled at warp speed -- adopted by thousands of customers, many of whom have generously submitted reports on the bugs and anomalies they found in early formulations of the Line Impact metric.
Upon revisiting how much our metric has changed since those early days, we realized that our v5 metric has become due for a v2 name.
When we first created our measurement, we chose to call it "Line Impact" because it evaluated individual lines of code, and we aspired to count only those lines that made an impact. As time passed, drift between "what the measurement is" and "what it is called" continued to grow. Today, we acknowledge that neither "line" nor "impact" precisely describes what we have built.
"Line" no longer matches because the measurement is not bound by the specific contents of the line; just as relevant is how that line relates to its ancestors and siblings. Further, whereas a line of code will not change after the commit is made, our measurement is constantly adjusting its past appraisals as later code reveals where churn transpires.
Also, it didn't help that when you mention "line," some will assume that the metric is related to "lines of code," the worst possible code metric.
"Impact" never closely matched what we measured, because the word carries too strong a connotation of being a value judgement. We hoped people would think of "impactful" as an antonym for "meaningless" (e.g., ignored code, find/replaced code). Many interpreted it as such, but some thought it imparted the sense that developers who didn't change code didn't have an "impact" on the team.
Also, it didn't help that GitPrime/Pluralsight's main metric is called "Impact," but has zero relation to our metric.
In version control systems, a "diff" is a commit. In the sciences, Δ or "delta" is used to indicate an amount of change.
When describing our metric to customers in 2022, we'll usually frame it as "an estimate of the amount of durable change occurring per commit." Boil the froth off that verbiage and you get "an estimate of the amount of durable change" = delta, "occurring per commit" = diff.
Considering the amount of code, documentation and videos currently mention "Line Impact" this was not an easy change for us to adopt. We are going to have to correct ourselves from saying "Line Impact" for at least the next few weeks. And as a general rule, we know that nobody likes change.
And yet, we now stand on the cusp of being able to connote to new customers what our metric does before we even start describing it.
We will no longer mislead new customers into thinking that our metric is connected to "lines of code," or to other metric providers offering their own incomplete assessment of "impact." Nor will we implicitly promote the idea that a code metric can judge the "impact" of an employee. A developer's impact is far too subjective and product-adjacent to judge through code changes.
Our focus is on providing the most reliable, customer-validated way to measure and improve the rate of durable code changes. If your business success depends on moving faster than competitors, chances are that you're focused on it too.