Lines of code are useful

Summary

At this point, we may be tempted to admit that Dijkstra was right all along when he wrote3 ewd 1036: On the cruelty of really teaching computer science; Dijkstra; 1998. Available online. My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. But it’s also not that simple. Lines written are lines spent, but some of them are also lines produced. Some of the additional complexity is accidental, and some of it is essential. The latter does indeed increase the value of the software. If the ratio of essential complexity to accidental complexity is relatively constant in a project (which it seems reasonable to believe, at least in aggregate across medium timespans) then the line count is also a measurement weakly correlated with essential complexity, i.e. with the amount of value the software can provide. This would be true also for individual productivity. If the ratio of essential complexity to accidental complexity is relatively stable for someone’s contributions one month to the next, then the number lines of code they have added to a project are a proxy for how much additional value they have made the software provide. However, different types of work has different proportions of essential to accidental complexity, so it’s not exactly a safe assumption that the ratio is stable unless averaged over many contributions.4 Goodhart’s law is also clearly a problem: if an individual is aware that they are judged by lines of code, they are likely to start producing more accidental complexity, which increases cost without increasing value. This reasoning makes it sound like it is never good to remove code, because that is correlated with negative productivity. That’s not what I’m saying! Removing code makes software cheaper to maintain. However, there is an important difference between removing accidental c...