Is using KLOC just to normalize size of projects still bad?

Question

I know many despise KLOC as some managers attempt to correlate that with productivity. But when we speak only comparing sizes of projects using the same languages and coding standards as well as the same tool for LOC calculation. Unlike story points, this seems like a more reasonable way that size of two projects can be compared.

Answer 1

The answer to this question will depend on your coding standards. The stricter they are, the less variation there can be in code produced by two developers, thus the closer the KLOC count will be for the same solution from different people.

But let's assume you work for a company that doesn't mandate every last detail and allows a degree of self-expression when writing code. To take an example, consider the following two ways of writing a method in C# for the fizzbuzz game:

Version 1

IList<string> GenerateFizzBuzzList()
{
    var fizzBuzz = new List<string>();
    for (var i = 1; i <= 100; i++)
    {
        var entry = "";
        if (i % 3 == 0)
        {
            entry += "Fizz";
        }
        if (i % 5 == 0)
        {
            entry += "Buzz";
        }
        if (entry == "")
        {
            entry = i.ToString();
        }
        fizzBuzz.Add(entry);
    }
    return fizzBuzz;
}

Version 2

IList<string> GenerateFizzBuzzList()
{
    var fizzes = Cycle("", "", "Fizz");
    var buzzes = Cycle("", "", "", "", "Buzz");
    var words = fizzes.Zip(buzzes, (f, b) => f + b);
    var numbers = Range(1, 100);
    return numbers.Zip(words, (n, w) => w == "" ? n.ToString() : w).ToList();
}

Both solutions are written in the same language (C#). Both solutions follow the same rules on naming, brace layout and various other conventions (eg using var) that are common in coding standards. Yet version 1 is nearly three times the size of version 2.

Scale these two approaches up to a moderately large app and we might have 80,000 lines in one project and 220,000 in another. But that 140,000 line difference is purely down to the approach taken, rather than because one does more than the other. KLOC can only tell you the comparative size of functionality if exactly the same approach to writing code is adopted for each project. In reality, exactly the same approach is only used by poor quality devs who never learn new techniques and ways of expressing code, ie in reality KLOC is just a measure of the number of lines of code. It measures nothing else so is of no use in trying to measure anything else.

Answer 2

Why are KLOC still in use ?

KLOC is neutral measure of the size of code, just as kilometers are a neutral measure of distance.

And just as KLOC, kilometers are not very useful: a larger number of km does not guarantee that the journey is nicer, more pleasant or with more sightseeing. Kilometers are also a bad predictor: they are not telling you how long it will take to reach the target, and neither how much fuel you'll need.

Yet, kilometers are still the main unit of measure for distance. And certainly for similar reasons, KLOC are still in use for size measurement.

What do you want to measure with KLOC ?

KLOC is a (very) bad indicator for productivity: writing a nice reusable and maintainable classes/functions can result in much smaller code, than dumb copy/paste/edit and repeating oneself for ever. But shorter code in same time might appear as less productive, although it's quite the contrary on the long run, since you'll need to code less thanks to reuse, and you'll need to test less, as you can rely on already tested components.

But KLOC is a valid measure of size. As every unit of measure, it has some shortcomings: not all lines are of same complexity, and layout and style can influence the quantity. But with some normalisation (such as ignoring empty lines and comment lines, or applying some pretty printing to neutralize style differences), over a large code base, it will have some statistical meaning.

Size only measures a quantity. It can influence compile time or reviewing time. It is used in litigations on intellectual property, to measure the degree of similarity between two different source codes. But don't expect it to be a good predictor of time, effort, or complexity (10 liens of recursive code are still more complex than 50 lines of sequential satements).

What are the alternatives ?

Story points are subjective to the team that made evaluation: you can't know for sure if this metric corresponds to size or to effort.

There are also function points that aim at more objectivity. But these are not readily available from the code and require an expensive analyse with also some room for interpretation (although less than with story points). I am also not sure they are still relevant in an OO worlds with GUIs.

Story points and function points are anyway estimates of requirements and expected features. They are evaluated before the code is written, and will in general not be updated if they appear to be inaccurate. They may give an idea of the complexity, but not at all of the size of the code that will be produced.

Answer 3

The problem with LoC for estimation is that you dont know in advance how many lines the final code will contain.

In terms of a post measure of the complexity and size of a project its as good as any other measure.

Assuming that people have a style of coding that they generally stick to and a speed at which they generally type. Then yes, you can look back at the code they wrote and see which tasks were easy and which were hard by the final LoC and the time it took for the dev to write them compared to their average speed.

This doesnt really help you in estimating future work though.

Answer 4

You're confusing two entirely different things here.

Managers care about functionality, because that's what marketing has sold. They don't care about project size at all except as an indicator for completeness of functionality. It's a very, very weak indicator, and only bad managers rely on it if there's anything better available, but it happens.

Programmers care about project size because that determines how hard the code base is to handle. They don't (primarily) care about functionality except insofar as that is what pays their checks. Unlike managers, programmers would prefer a smaller code base, other things being equal.

This means that the two situations are not comparable at all. KLOC is a useful measure to judge project size, and a very useless measure to judge completeness or productivity. There is no contradiction here.