Excerpt from a Kata Lesson regarding the creation of code that counts lines of code. It did not necessarily condone the LOC method, but rather the opposite. However this was merely an excercise in solution building to tune development skills.

So whats the reason for this posting? To further exemplify my difficulty in understanding why *any* organization would would want support LOC as a valid method of determining function value metrics. Everything I have read demonstrates that the data derived from the method is pretty much a waste of the effort that goes into analyzing it. By going back to the roots of function value measurement, function points becomes a more legitimate method of measuring and sizing of software. Function points can also be seen cross platform as they are less technology dependent.

With all this said, I can see only one viable environment where LOC is valid: Automated Code Generation. So if the code is auto-generated, then the structure and format is consistent. However, as long as there is a human element involved, the value of LOC begins to degrade rapidly as the human engagement increases. Furthermore, across the organization if we are not able to leverage automated code generators, we lose the ability to get a true picture of cost. Function points again meet this issue head on by allowing us to not only measure across platforms consistently, but also help us identify which technology platform may be better suited to the need. In many cases, we use the tools we know in our area without consideration to other options that could be available within the organization.

Preface to Lines of Code Kata Lesson

Using metrics to measure progress is not inherently bad, but you have to make sure that you measure meaningful things. Measuring business value delivered over time is a good idea (if you can find a way to do it). Measuring lines of code is not. Why? Because on its own, a line of code is not particularly meaningful. If programmer A takes 100 lines of code to achieve the same functionality that takes programmer B 10 lines, is A ten times as productive as B? Quite the opposite.

At a lower level, there will also be fights over what a line of code is. This story from Brian Marick makes the point: [counting code lines] was my very first assignment in my first full time job. One thing I discovered was that our shop had two styles of using braces:

if (foo) {
}

if (foo)
{
}

Users of the former were outraged that the tool saw users of the latter as 50% more productive. That was the beginning of my long non-romance with metrics.