We all know that the less lines of code (SLOC), the lower the maintenance cost, right? Not quite. As with most things in this world, there exist marginal returns in the pursuit of brevity.
Over the past few years I’ve been working a lot more with Ruby and the Rails framework. I’m not sure why, but there seems to be a social norm in the community of impressing others by consolidating code to as few lines as possible (often just one) with the (mistaken) belief that the code is better. And that sometimes makes me feel like this.
Those programmers that create some of this amazing, yet arcane code are usually some of the best programmers I’ve ever worked with.
The problem is that they’re often misguided in this pursuit of brevity.
The relationship is probably not linear and there is likely not only diminishing marginal returns (which are almost always inescapable), but there is likely a negative relationship at some point. The reason is that although the advanced programmer can handle the complexity of the “arcane” lines of code, those that maintain code are often not the ones writing it – specifically and also in skill level. The more arcane the code is, the more time it will take those maintaining the code to understand it.
The relationship is probably like this graph.
It’s been my experience that good programmers do not need to be reminded of writing DRY and concise code. Quite the opposite. As a project manager, I believe it is necessary to inform and remind those great programmers of the potential for increasing costs due to an overemphasis on the reduction of lines of code. Strange but true.
2 Responses to “Line count and maintenance cost”