Why LOC is a Redundant Way of Calculating Productivity

Throughout my career, which is entering it's 10th year of commercial programming, 15 years total, I have always been bombarded by the CTO's and the "good" programmers, who boast that their product is x amount of lines long. Sometimes, 100,000's and sometimes in the millions. And naively, I would always say "WOW", that's a lot of code. And on more than one occasion, I would look through the code and think WTF!!!

The problem

First off let me say that, when commenting on the lines of code you are writing for a project, there will be some people who would still be wowed by the thousands upon thousands of lines of code. I mean which is cooler : "Our product has been in development for 10 years and has 1 million lines of code" or "Our product has been in development for 10 years and only has 100 000 lines of code".

From the bat, most of you would say, wow cool, the former is way better than the latter. But here's the catch. Let's take the following criteria.

• How complex is the system. 
• What language is the system written in.
• Is it a front-end or back-end based system.
• What API's are we using.
• Does it interface with a persistence instances.
• What was the level of programmers who was involved with the project over it's lifetime.
• etc etc

You get the picture. There are many variables coming into the picture and all of them has a knock-on effect when it comes down to the number of lines of code that will be in the system.

The old world

Many a language, serves a purpose. What I mean by that statement is, that every language has it's purpose and strong point. You use a language what it was designed for. I might get slated for this, and this is in no way a very concise example.

• For text processing, use Perl or Python.
• For size and speed, use C or C++ (obviously ASM would be better, but the development time would go through the roof)
• For rapid application development and prototyping, use Java or .Net.
• For web applications, use Ruby on Rails.
• For web services, Java.

You can see my train of thought there. Use what the language was designed to be used for and you would get 100 times the benefit.

But here comes the conundrum. As with most of these languages cannot, or do not like to be used with each other. I mean, sure you could probably use Java web services with Ruby on Rails etc, but that's bastardizing the integrity of the program, not to mention, after a while, it becomes a nightmare to manage different languages in a system. So what developers do, is they create API calls to suit their need to do what the other language would do. Some of these languages also would take 10 lines of code to do what a 4 generation language could do in 5 lines.

The new world

Recently, there has been a big push to create languages that would require less code to complete a task. This has made coding, for the most part, easier and programmers more productive. A simple example would be a simple hello world program.

Scala

object HelloWorld extends Application {
   println("Hello, world!")
}

Java

public class HelloWorld {
   public static void main(String ... args) {
      System.out.println("Hello world!");
   }
}

Now this is a very simple example of how to save some lines of code by using some of the newer languages out there. The problem here though, is that on some occasions, you would have to extend the new language in order to implement some functionality which older languages already has. Which would add lines of code again. The same could be said, when converting a C or C++ program to Java. Aaargghh my brain hurts.

Programmer level

Ok so now that we see that, by using different languages, we can save a lot of lines of code, the next logical step in the equation is : the level of your kung fu. Are the developers who wrote that system of 1 million lines, the best of the best ?

Let's again take a simple example. 1 method to do exactly the same thing.

Novice (For demonstration purposes only)

public void novice() {
        int i = 0;
        int maxLoop = 10;
        int printAt = 5;
        while (i < maxLoop) {
                String word = "";
                if (i == printAt) {
                        word = "Booyakasha";
                } else {
                        word = "Yakashaeboo";
                }
                System.out.println("Hello world : " + word);
                i++;
        }
    }

Intermediate (For demonstration purposes only)

public void intermediate() {
        int maxLoop = 10;
        int printAt = 5;
        for (int i = 0; i < maxLoop; i++) {
                String word = i == printAt ? "Booyakasha" : "Yakashaeboo";
                System.out.println("Hello world : " + word);
        }
    }

Expert (For demonstration purposes only)

public static void expert() {
        int maxLoop = 10;
        int printAt = 5;
        for (int i = 0; i < maxLoop; i++) {
                System.out.println("Hello world : " + (i == printAt ? "Booyakasha" : "Yakashaeboo"));
        }
    }

Please note, these aren't the best examples, but you get the point. The higher level of programmer would make methods simpler and use less lines of code to come to the same conclusion for a method. This is also where complexity through simplicity comes in. The saying, if I recall goes something like this : To make a simple thing complex is easy, to make a complex thing easy, is hard. Or something like that.

Problem solving

This is the hot topic right here. While coding, most of us will spend large amounts of time investigating ways to implement code. Be it to learn how the API works through reading up of documents or googling to find examples of how to implement a piece of code.

This time, which is regarded as research and development, should also be factored into a project as it will probably take up a sizable chunk of your time to figure out how to implement the latest and greatest new language feature or API or whatnot.

And this, my friends, cannot be factored into lines of code. Not to mention, when writing code, looking at some examples, seeing that what you have done for the last 100 lines are wrong, deleting it all and starting from scratch, 2 or 3 times. Every time churning out 50 to 100 lines of code, but when it comes down to actually committing your code, it's only 20 lines long. So how much was your productivity ? 150 lines ? 200 lines ? 20 lines ? This is really hard to calculate unless you are using some super duper character counter which knows comments from real code too, because comments aren't really code.

Conclusion

We have seen through not so useful or accurate examples, that there are many variables which contribute to the size of a program. And thus using lines of code as a measure of productivity is kinda pointless.