The Case For Using Lines of Code In Metrics

John Hartley
4 min readOct 10, 2022

Are you nuts?

Slaps Hand. TOO MANY LINES! — Photo by Danial Igdery on Unsplash

Maybe, but let’s dive a bit further and see where we end up!

The History of Lines of Code and Goodhart’s Law

Early in any programmer’s career journey they hear some variation of the Bill Atkinson at Apple story. Essentially he had a major win for QuickDraw back in 1982 by removing 2,000 lines of code from the module, but had to input how many lines he wrote into his daily productivity form. If legend is to be believed, this entry in 1982 was the first middle finger to Lines of Code as a metric.

The removal of that code made the system much better, but by the measure, Atkinson was doing a poor job.

Goodhart’s Law states:

When a measure becomes a target, it ceases to be a good measure

Managers at that time lacked creativity and zazz and went with one of the only measurables they could see. In their minds, lines of code = productivity = good employee. I see what early managers were trying to get from the metric, but there are some glaring problems.

Lines of Code as a Measurement

At the heart of this measurement, lines of code is “how many lines of code written to perform the task at hand.” On the surface, pretty straightforward, yes?

Alone, lines of code is a bad metric. It does not scratch the surface of effectiveness, quality, or efficiency. If desired, I could write my entire program in one line of code. Doesn’t mean it’s good or that it works, and think of the engineers that would mutiny over maintenance.

My teammates trying to find the error in my one line of code.

On the other end of the spectrum, I could break my program into as many lines as I want to hit your dumb measurement.

When I started as a front-end engineer, you would have thought me a regular Zuckerberg by the number of lines of CSS I could crank out. In reality, my CSS was gigantic, gross, and impossible to maintain.

Lines of Code as a Measurement Tweaked

--

--

John Hartley

Engineering leader with a passion for building and growing teams. Writing about leadership and management in the tech industry. Director of Eng @ Curology