Francois has posted 1 posts at DZone. View Full User Profile

Why LOC is a Redundant Way of Calculating Productivity

  • submit to reddit

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.


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



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);


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.



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.


Published at DZone with permission of its author, Francois Hensley.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Ricky Clarkson replied on Wed, 2009/09/23 - 3:44am

Scala is neither loosely-typed nor dynamic.  It is a statically-typed language, with a more useful type system than Java.

Java's problem isn't that it's statically-typed.

Here's a measure for you; lines of code deleted (without removing functionality).  I deleted 5,000 last week.

Danny Lee replied on Wed, 2009/09/23 - 5:25am

I like your example :)

The method named "printHello100Times" and not prints "hello" 100 times, bet "Hello world" only once, it's like real life.


Francois Hensley replied on Wed, 2009/09/23 - 5:49am in response to: Ricky Clarkson

Semantics. All I'm saying is that sometimes, less is more.

Francois Hensley replied on Wed, 2009/09/23 - 6:15am in response to: Danny Lee

hehehe, I bet you it does only print once. Bad example of method name I know. Next time will be better. I hope.

Vedad Kirlic replied on Wed, 2009/09/23 - 6:54am

I agree with your points except for part regarding Scala. I suggest you to remove or everything under "The new world", or change example with another, dynamic and loosely typed language that cannot interact with Java nicely (everything that Scala isn't). Several facts:
  • Scala is statically typed.
  • Scala has expressive type system.
  • Calling Java from Scala is as easy as Java from Java, even easier (more concise) in some cases.
Again, I agree with general point of your article.

Francois Hensley replied on Wed, 2009/09/23 - 7:55am in response to: Vedad Kirlic

Thanks. I removed the references of Scala except for the examples. I'm not saying that Scala and Java can't co-exist. I'm pretty sure they can, but have you ever tried to create a JNI based system ? Or even trying to execute Perl scripts from C or C++ through their API. It's painful. But besides being painful, when the project start spiraling out of control of complexity, it becomes a nightmare to manage 2 or even more languages.

Ronald Miura replied on Wed, 2009/09/23 - 8:58am

I don't agree with just one thing: using LOC to measure productivity is not redundant, it's just plain stupid :)

Jon Baso replied on Wed, 2009/09/23 - 10:07am

I disagree on your 'level of kung fu' statement.  Just because the code is brief doesn't make it readable.  You can use shorthand that only 2/3 of your developers will understand, but that doesn't make it good.  Is the shorthand code any faster/optimized than the "Novice" code?

Anthony Goubard replied on Wed, 2009/09/23 - 10:24am

Here are a few points:


  • when reducing the code ask yourself "is it more readable?" -> it should be
  • think of using libraries/framework like Apache Commons (IO, lang, ...)
  • have someone assigned to review your code. Tthen you're less likely to use copy/paste or write ugly undocumented code.

Developer Dude replied on Wed, 2009/09/23 - 11:21am


I think you at best glossed over the most important criteria when comparing code bases. A couple of people hinted at it, or mentioned it indirectly: quality of code.

Regardless of purpose, language(s), API, or any of the other variables, I can sit down and output thousands of lines of crap code every day - one of the easiest ways is to use the old tried and true copy/paste/tweak methodology widely used throughout the industry to this day (despite denials I am sure).

As we all know, writing thousands of lines of buggy code, or even copy/pasting less buggy code, is not productivity - and yet that is often what is measured when these examples are given. I assure you, give me a problem and I can output a lot more lines of poor quality code faster than I can output higher quality code that uses fewer lines - not to mention designing code for reuse, testability, readability, code that has high cohesion and low coupling, etc. (all of these are actually aspects of quality).

Then there is the issues of tests - have unit/integration test modules been written? Are those modules high quality or are they just low quality 'smoke tests'? How many bugs did the tests find?

Most devs don't write good test code - they have neither the experience nor the mindset.

What about documentation?

So, where are the metrics for those deliverables/criteria when KLOC is quoted? Usually nowhere to be found. In part because the people who put out the KLOC numbers either don't know or don't want you to know, in part because sometimes these metrics are not easily measured (despite some metrics that purport to measure them).

Yes, use the right tool for the right job, but regardless of the tool, use it correctly and wisely, producing a quality system. In the long term, even the short term, quality matters more than quantity. What should be measured is whether the goals, the milestones of the project, are reached and those should include some measure of quality.

KLOC is not a redundant metric with regards to productivity, it is mostly irrelevant. KLOC should only be used in conjunction with metrics of quality to put the system and other metrics in context. Show me a 'hello world' that is 1 KLOC and I will start wondering about the quality. Show me an operating system that is implemented in 1 KLOC, with the features of OSX, and I will start wondering what genius has that kind of skill.

Mrmagoo Magoo replied on Wed, 2009/09/23 - 8:36pm

Really? There are still large numbers of people out there that use lines of code to compare who/what is better?? I think the fundamental premise here is quite the straw man. But then this reads more like an advert for Scala rather than addressing a common real world problem...

Francois Hensley replied on Thu, 2009/09/24 - 1:37pm in response to: Mrmagoo Magoo

Definitely NOT an advert for Scala. I just used it as reference.

Kathleen Erickson replied on Tue, 2010/08/17 - 5:53pm

Actually, lines of code can be a measure of productivity when it comes to automating certain portions like integration. When you factor in the number of lines of code that don't have to be written the savings are significant AND the developer can be more productive on other aspects of the application code.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.