The Case For Using Lines of Code In Metrics
The Case For Using Lines of Code In Metrics
Are you nuts?
Are you nuts?
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.
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
As in my poorly-written CSS file lengths, the greater the lines of code, the more difficult it is to maintain and reason about. Instead of looking at the raw lines of code, let’s view it more around complexity and efficiency.
The least amount of lines to accomplish a goal should get more discussion than it does today. It must also be considered with diminishing returns. If you look at answers in CodeWars, you’ll see tight, succinct answers to challenging katas.
When you see those few lines though, are you able to easily understand what it does?
Too many lines of code is likely too complex, too little is likely too time-consuming, so what do we do?
The Right Lines of Code + Desired Outcomes = Succinct Success
This is what we’re looking for. Did the program do what we needed it to do to achieve our desired outcomes? Is the code readable and at a low line count? Congratulations, that’s a successful use of this metric.
To answer what is “the right lines of code”, consider:
Maintainability
Effectiveness
Efficiency
Speed to write
There is an intersection point of the those four items that varies between all teams. Depending on the company, the team, and the project, each holds different weight.
Ask your team, “which of these four things do we value the most when we’re working?” I bet you’ll get some interesting answers.
Net Lines of Code
Something that doesn’t get talked about enough is the removal of code.
The Bill Atkinson example above shows that sometimes only removing code is the most beneficial outcome.
Rewarding negative net lines of code should also be more common. Typically, we work on projects and products that create more tech debt than they resolve.
The next time you see a big chunk of code removed, celebrate it! 🎉
Have We Made Lines of Code A Good Metric?
Maybe, but that all depends on how it’s used. As a raw measurement, Lines of Code is garbage. Combining outcomes, timeline, and net lines of code written/removed, we get closer.
When we inspect all aspects together, we get an interesting insight into how the team works. While it should never be a number to measure directly, inspecting a PR from time to time with this lens is beneficial.
There are trickle down benefits as well. Less lines of code leads to smaller pull requests, easier reviews, and more productive conversation.
The easier it is to review, the easier it is to catch mistakes, and prevent prod-breaking bugs.
Final Thoughts
Please don’t blindly apply lines of code measures to your teams.
Used in concert with other measures, lines of code is an interesting data point that gives you more information than velocity as a metric.
For starters, you begin to understand the thought process and the how of getting to a solution. Give it a shot this next week and see what you learn.
What metrics does your team find helpful? Inspecting and assessing engineering metrics is fun to me, so I’m always curious what’s been the most advantageous for teams. Let me know in the comments!