You probably don’t want your team being paid based on lines of code. But writing lots of code is also a good idea.

Why we hate measuring lines of code

We asked a bunch of people why they hate the idea of measuring lines of code so much. Given that we’re sort of obsessed with quantifying engineering work, this seemed like an important question to answer.

The results here varied quite a bit, with people saying “because people will just write lots of terrible code” or “that’s a very easy metric to game.”

All of this is true, of course. But lurking below the surface among all of the sentiments was an underlying thread: We don’t like measuring lines of code because it’s offensive.

Computer engineers are wildly brilliant people, and yet this brilliance is constantly misunderstood and the specific nature of that brilliance is not commonly recognized by the ‘civilian world’ (non-developers). Engineers are weird. This is perhaps most hilariously illustrated by engineers themselves, who we've heard describe interactions like this while heroically fixing bugs on weekends:

"Dear, stop fiddling with your computer."

"MOM I'M A PROFESSIONAL ENGINEER FOR GOD'S SAKE"

These are great anecdotes, and they show how generally reductionist non-developers are about software engineering work. There’s lots of subtlety to being a great engineer, and this can’t be reduced down to a single, contextless metric. Doing so strips out all the artistry and is… well, it’s disrespectful.

You don't pay a Michelangelo to make brush strokes - you pay him to be a genius.

One of the best metaphors to describe this is by comparing it to other subtle arts. Michelangelo, being the fantastic artist that he was, was paid handsomely for his work, but he was never paid by the brush stroke. That’s because you don’t pay a Michelangelo to make brush strokes — you pay him to be a genius.

Software engineering is essentially the same arrangement.

When Brush Strokes Matter

This is not to say brush strokes don’t matter to a painter — all great artists are by nature prolific. Every one has thousands of sketches, drafts, versions, and notebooks. They paint and draw and sketch because above all else they love to create and a large body of work is a nature result of a lifetime of creativity.

The same is true for programmers: all great coders love to create, and lots of code is a natural result of that love. So it is reasonable to accept that all great coders output a lot of code, even if not all voluminous outputs flow from great coders.

If we apply a little set theory, from this basic truth we can also logically conclude that coders who do not produce a lot of code are by definition excluded from the set of great coders.

This is perhaps best illustrated by the following anecdote from the book “Art & Fear:” ¹

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. On the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot -albeit a perfect one - to get an "A".

grading time a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

²

Experience comes from practice, and when it comes to practice, sheer volume really is quite important. If we’re to believe that software engineering falls into the ‘artistic’ class of vocations, then we should assume it’s also governed by the same artistic maxims.

Coders who do not produce a lot of code are by definition excluded from the set of great coders.

So how does this relate to lines of code?

LoC as a proxy for domain knowledge

When you learn a new programming language, much of the knowledge of other languages is transferrable. But still, there’s nuance and subtlety unique to every programming language that requires some practice to truly master.

This same concept applies when joining a new project. Each new project requires a train-up period on unfamiliar patterns, different coding standards, naming conventions, etc.

It’s pretty easy to imagine that lines of code contributed to a particular project, or written in a particular programming language would be a reasonable proxy for the domain-specific knowledge associated with that field.

Just like the example above where ‘throwing a lot of pots’ makes for experienced potters, writing a lot of code has a tendency to make for experienced programmers. Like any other profession, true experience is gained in the field not from a book. For software engineers, writing code is the field.

This is an important insight if you’re looking to be a programmer: writing lots of code is probably good for you.

This does not, however, mean it’s something that can be used to incentivize programmers, or which outsiders can use to judge development work. Here, we see the real problem: nuanced data requires a nuanced interpreter.

For example, while it’s almost certainly true that more coding makes a better programmer, for most instances of programming, the reverse is true: being economical about the amount of code used to tackle any one problem is also good.

Data is only dangerous in the hands of idiots

Any poison that lies in measuring lines of code comes not from the information itself, but the actor who uses it.

Consider again the story of the ceramics teacher. Even in that example, which is explicitly pro-volume, the measure of quality is external: it’s not saying “making more stuff is inherently good.” Instead the lesson is that “making a lot of pots is a good way to learn how to make quality pots.”

The students’ work — and the result of the experiment itself — were both still evaluated through the eyes of a seasoned expert. And so it should be for a healthy engineering team: engineering work should always be evaluated by a team lead who knows what they’re looking at.

It’s an unfortunate fact that this isn’t widely accepted with regard to software development. Several popular methods of managing engineering work implicitly assume all software development work can be managed in a purely procedural fashion by a relatively naïve manager. This means that it’s a not-uncommon experience that those who manage developers are not, themselves, seasoned programmers. It’s this fact — not concern over being asked to write lots of code — that triggers a feeling of despair whenever the pointy-haired-boss suggests measuring lines of code.

The worry over lines of code (or other ‘hard’ metrics) isn’t actually concern over the data or more visibility, it’s a broader sign that feedback developers get is low-quality, and too often comes from outsiders who don’t really understand the nuances of software engineering.

But note that the solution to this problem is not to banish certain types of data from the discussion. Instead, we need to be better at selecting the people who designs the success conditions for software teams, and who give feedback on developers’ work.

These people — in engineering and other disciplines alike — should always be true masters of the craft practiced by the teams they’re leading.

Notes:

David Bayles, Art & Fear: Observations On the Perils (and Rewards) of Artmaking (2001) ↩ 

Photo: Dan Finnegan, A Week of 100 Mugs ↩