Lines of Code is a Bad Measurement
Why This Persists#
We know lines of code is a bad measurement. Dijkstra told us this in the 1980s. Gates reinforced it. Thompson demonstrated it through practice. Every experienced engineer you ask will agree. Yet here we are, still watching organizations adopt it as a productivity metric.
This persistence matters because it reveals something about how easily metrics seduce us. Lines of code is trivial to count, simple to compare, and generates satisfying quantitative data. It looks like objective measurement without demanding the messy work of judgment or domain expertise. Understanding why this particular metric fails helps us recognize similar traps before we stumble into them.
The Wrong Unit of Measure#
Dijkstra called lines of code a “costly measuring unit” because it fundamentally inverts what we value. When we write clear, maintainable code, we work to express ideas concisely. A well crafted function might accomplish in five lines what verbose code does in twenty. But if you measure productivity by lines written, the verbose implementation scores four times higher than the elegant one.
This is not a minor scoring quirk. It actively rewards the opposite of what good engineering requires. We need clarity, which demands economy of expression. We need maintainability, which depends on reducing cognitive load. Yet lines of code treats more as better, encouraging exactly the verbosity that makes code harder to understand and maintain.
Software Isn’t Manufacturing#
Gates once compared measuring progress by lines of code to measuring aircraft quality by weight. A heavier plane is not a better plane. Weight is a cost the aircraft pays, not a benefit it delivers. You want the lightest structure that safely accomplishes the mission.
Software works the same way. Code is what we have to maintain, what we have to understand, where bugs hide. More code means more surface area for defects, more cognitive overhead for changes, more coordination across the system. The manufacturing mindset treats output as value, but in software, output is cost. Good engineering minimizes what we build while maximizing what we achieve.
Engineering Is Reduction#
Thompson once remarked that his most productive day was when he deleted a thousand lines of code. This captures something essential about engineering work that lines of code as a metric completely misses. The goal is not to produce artifacts. The goal is to reduce complexity while solving problems.
Good engineering work often involves making systems simpler. We refactor a tangled module. We recognize that two abstractions can become one. We find a feature that adds complexity without delivering value and remove it. Lines of code treats all of this as negative productivity. It makes the work of simplification invisible or worse, frames it as destruction.
Constantine’s Equation shows why this matters economically. Software cost grows exponentially with the difficulty of making changes. Every unnecessary line increases that difficulty. The best code is often the code we never had to write because we found a simpler solution.
Output Theater#
The real danger of lines of code is not just that it measures the wrong thing. It shifts the conversation from outcomes back to output. Instead of asking “did we solve the problem?” we start asking “how much did we produce?” This transformation is subtle but corrosive.
As I discussed in In Order To, teams need to maintain clarity about why they do what they do. When we measure lines of code, we optimize for motion rather than progress. The team completes the ritual of writing code, generating impressive metrics about productivity, while perhaps accomplishing nothing meaningful. Speed without comprehension does not accelerate delivery. It compounds risk.
Measurement Seduction#
We adopt metrics like lines of code because engineering judgment is hard. It requires understanding the domain, evaluating trade-offs, and accepting ambiguity. A simple count feels objective and fair. It removes the discomfort of subjective assessment.
But measuring the wrong thing precisely is worse than measuring the right thing imperfectly. Lines of code gives you exact numbers that tell you nothing useful about whether you’re building the right thing well. It creates the illusion of management while obscuring actual progress. The comfort of quantification isn’t worth the cost of optimizing for entirely the wrong variable.