A corresponding thought-experiment is to consider the results of the opposite situation: if a manager read this article, and simplemindedly decided to measure by lines of code removed instead. Would that make things better or worse?
Easier to be gamed depending on the company and method of measuring; let llama dream up code that looks fine, add some code so the code has no actual effect, commit, remove at some time later. Any measuring of this kind is pretty much useless you have solid code review practices in general place (which, unlike people here like to believe, is a rarity). But with good reviews, underperformance and gaming the system would also be caught so you would have less reason to implement metrics like this.
Marginally worse, but not as bad as you'd think, because the industry already has similar shortsighted impulses in that direction.
For example, the perennial idea of replacing all the software engineers and their arcane code-text with product-managers drawing some special diagrams or flowcharts for "low"/"no"-code results.
Any line-based metric should be suspect, but 'delta-SLOC' is probably the least bad. I would count added lines and removed lines separately, so a +50,-150 patch would be 200 ΔSLOC.
This isn't a good measure of productivity, especially not in isolation, but it's a reasonable napkin-math metric of change. A developer with a high ΔSLOC count may or may not be more productive than a peer who has a week or two of no ΔSLOC at all, depending on what that peer is up to, but the first of these is definitely changing the codebase more than the second, during the measured time span.
There is I believe a specific context where removal is good and others where that is not the right measure
I'm working on some java 8 cide that was written by folks still living in java 1.4 land, lots of opportunities there to reduce 20 lines into 3 (plus those devs kinda insisted on doing things in painful and unnecessary ways). In parallel, I'm working on a Greenfield project. Even on the Greenfield, there are times when negative code added is good. Not all programmer activities are equal
It's like measuring gas consumption during emergency braking, during acceleration, and during normal highway cruising. Sometimes it firs, or kinda fits, other times it's just the wrong metric. Programming is not a homogeneous activity
ΔSLOC is just a metric, and what it measures is change to the codebase. Yes, some changes are very important, and others nearly trivial, so it's quantitive because a qualitative metric is a contradiction.
It certainly means different things in different contexts, if it's even meaningful at all. My claim is that +SLOC is entirely meaningless outside of the tautology that it measures what it is, where ΔSLOC is in fact informative about change to the software, albeit not perfectly so.
My hope is to convey more texture here, that programming is more than just one thing. EG: "Today I was mostly debugging". That could have its own measures. I think in large part the measures of programming productivity are often too reductive, the measure is incomplete or tries to measure "programming" rather than its _many_ distinct sub-activities.
If the product is "finished" then it would probably be equal or better (otherwise the negative LOC change wouldn't make it to prod).
But most products are ever evolving (that's why we have the luxury of remaining on the same project for years), so just negative contributions will invariably not add anything.
Metrics that are team level dashboards and not shared outside of the team are different from pay and promotion incentivized metrics. The same metric can have very different behavioral outcomes between the two scenarios
