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…



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