Apr 20, 2012

Code is a liability

My attitude towards lines of code as a metric has changed drastically during the last several months.

We all know LOC is a meaningless measure for productivity estimation (and here I regard as LOC any simple counting metric on the codebase: it can be "words", "whitespaces", "keywords" etc.). Well, what this metric can show is that you can e.g. sit down and churn out 5000 LOC per evening. The amount of LOC for a given task can differ across languages, so let's consider that LOC is already "discounted" for a language. Still, use of this metric for estimating productivity or project progress is questionable.

One question is that even "optimal" LOC differ wildly across tasks. Adding a cool new feature can be 1 LOC, and refactoring for the sake of beauty can be 10 kLOC. Tests "write themselves", so tests (if you include them into measurement) can add times more than the functionality they test.

But there's more to it.

Adding a feature by using a third-party tool and several lines of code is faster, more reliable and overall "better" than writing it all yourself (which is more LOC). Basing your product on some technology that allows you to make your LOC 10% compared to what it would be without using it is better in the same sense, too. It gives you competitive advantage. I feel that most startups are about it: having an idea that is useful for people *and* for which a technology stack exists allowing it to be implemented with few LOCs and few configs.

It doesn't only apply to the "start". For a startup (and IMO to any product) it's important to maintain the product focused by only adding the necessary features (to fight feature creep and scope creep) which should be as coherent technologically as possible. Common parts should be reused. Codebase kept small.

I started to understant the "functionality is an asset, code is a liability" mantra (the linked post gives cool examples of what I've been trying to formulate abstractly).

Is {0 LOC, 0 added value} better than {N LOC, much added value}? I claim it is if the added value isn't that aligned with the product and worse otherwise, so "0 LOC" is incomparable to "N LOC" in and of itself.

Then why do some people, me previously (I hope!) included, tend to view the "amount of change" as a metric where more is better? Reflecting over my own beliefs, I think there can be at least two explanations. First, I tend to think that there's some "inherent" to a problem amount of work to be done. Seeing big LOC change gives me an idea that something important was done. It's probably not the case, or even sometimes this "something important" can be an important overall degradation. Second, I simply believe that change is always good, and that no LOC means no change.

These days I think neither of the two is the case.

No comments:

Post a Comment