tape-measureSoftware Managers all around the globe, need to have some metric to estimate their workers. Sometimes the management event wants to create a precise and measurable way to know the programming progress and the developers productivity and performance. One of those methods is called SLOC – Source Lines Of Code. This metric is used measure the size of the software by counting the lines of the program source code. Some managers tend to love SLOC because it can be automated so it requires very little effort and the effect of it can be visualized. That is exactly what managers like! it is easy and it can be easily inserted into their reports, what could be better than that? It seems just perfect.

Well, those managers forgot one little issue here – this metric does a very poor job in measuring programming progress and developers productivity. I think that the amount of line of code is meaningless and it tells nothing about the project or about the developers. Let me quote Bill Gates: “Measuring programming progress by lines of code is like measuring aircraft building progress by weight“. I would add another analogy: Measuring programming progress by lines of code is like measuring house building progress by size. Building the skeleton of an house takes 3 month while the completion of it takes 1 year. If the construction manager would measure the progress by the size of the house, he would understand that the first three month were very productive while the other nine month were very poor and the workers were lazy! It is the same with software projects, it is more likely to gain the biggest amount of code line by the beginning of the project. Another thing is that it tells you nothing about the complexity of the problem, sometimes using a design pattern can decrease the amount of written code, is it a bad thing? Skilled developers may be able to develop the same functionality with far less code! An experienced developer will implement some functionality in fewer lines of code than another developer with relatively less experience, though they use the same language.

I think that those who use SLOC is wasting their time and I am sure that they can find better things to do, if they don’t – they are just a spoke in the project wheels and they will be more helpful at home. This method creates a negative psychological impact on the developers, a programmer who is being measured in lines of code, will be rewarded for generating more lines of code even though he could write the same functionality with fewer lines. What do you think? is there a possibility that he will “blow” his code with unneeded complexity?

Tags :

21 Responses to “Measuring Programming Progress By Lines Of Code”

  1. Nick Cage

    Said on September 9, 2008 :

    So give us a better metric.

  2. Shahar Y

    Said on September 9, 2008 :

    @ Nick Cage
    I will post about it in the following weeks.

  3. Jonathan Starr

    Said on September 9, 2008 :

    In my opinion, a better metric is velocity – the number of estimated/ideal hours for tested components that were created and deployed to the target environment (production or demo) per iteration. This needs to be adjusted by bugs created in an iteration.

  4. skitzo

    Said on September 9, 2008 :

    This is why I love languages that do not restrict whitespace.




    I’m super fucking productive!

  5. Bart Czernicki

    Said on September 9, 2008 :

    SLOC is actually not that bad if you are using fully vetted specs. I worked at places where we had marketing/functional/technical spec fully locked down to the hour and pseudo-code. If you assin that to a developer and he is producing only 200 lines of code / week. There is a problem.

    I completely agree with all the diffences you mention…thats why SLOC derivatives are better than SLOC alone.

    I am not some big proponent of SLOC, I do think it does give you some kind of baseline. For example, there are tools that exponse SLOC metrics as KPIs. The manager can then see the developers that are doing a poor job, quickly drill into their work time sheets and see…”Oh this guy was at a conference” or “this guy was on this”. I have seen tools like this used pretty effectively before managing decent sized teams 50+ developers. The number might be misleading, but a high level u can drill into why.

    “sometimes using a design pattern can decrease the amount of written code” …actually almost all of the design patterns INCREASE the amount of code.

  6. Marcos Silva Pereira

    Said on September 10, 2008 :

    Ok, so, today I finished a refactoring and I remove some lines of code. OMG, I have negative productivity!

    Kind Regards

  7. Abdullah Cetin CAVDAR

    Said on September 10, 2008 :

    SLOC is used as a software progress metric used by lots of the companies. It can be used and measured according to me. However, it cannot be the only metric that defines the plans and progress. As far as I know, Function Point is another metric used and i think, it gives more healtier results for estimation.

    Function Point: http://en.wikipedia.org/wiki/Function_point

    Thanks for the post.

  8. bm

    Said on September 10, 2008 :

    A feature driven development, and actual implemented features count looks more useful.

  9. Niki

    Said on September 10, 2008 :

    This sounds a bit like “you shouldn’t use ‘miles’ to measure travel progress, because the number of miles doesn’t tell you how long it’ll take till you reach your destination, or if you’ve been driving in circles.” That is, maybe you just don’t know what SLOC are good for?
    Your house-buiding analogy is quite good I think: Nobody in their right minds would use size as a *progress indicator* for houses. But does that really mean that “size” is a useless measure, and that those using it are wasting their time? IMHO it would make sense for a builder to tell his client at the beginning of a project something like “a house of that size would take about 6 months to build, with 10 people working on it full-time, and an estimated cost of X”. Of course that doesn’t mean that every meter of a 10m house costs exactly X/10. Everybody knows that. But still, on average, and for comparable, the total size of a house is a handy indicator for the total cost of a project, for the cost of maintaining it, and so on.

  10. Regev Porat

    Said on September 10, 2008 :

    It’s not enough simply to point out that counting the amount of code-lines isn’t good, you need to suggest a better way for managers to estimate the project’s progress or to evaluate the developer’s contribution. In other words, maybe SLOC is like democracy – it sucks, but it’s the best thing we have.

  11. fsilber

    Said on September 10, 2008 :

    Actually, Bill Gates’ analogy (measuring weight in airplane building) was better than yours (measuring the area covered by a house under construction). The size of a house may not increase whatsoever once the frame is up; the size of the codebase and the weight of an airplane do increase as parts are added. The size of a house is an important aspect of a house’ value for its own sake — not so for weight in airplanes or code-size in software. On the contrary, at any given level of power a plane’s weight counts against its payload (besides adding to running costs). At any given computer speed and memory size, code size is a limit to useability and maintainability.

    People may reject a house solely on its being too small; no one ever rejected an airplane that met all other spects solely because it didn’t weigh enough; no one ever rejected a program that satisfied all its requirements save for a minimum required number of lines of code.

    In that sense, code-size is not even analogous to miles traveled — even though you may get lost and go into circles, a successful trip is defined by the number of miles traveled in the correct direction. Not so for software development — no requirements document ever says something like “must contain at least 100,000 lines of properly-targeted code.”

    The only way to measure progress is via verifiable milestones in a development plan. My milestones, I mean sets of tests that the current codebase is able to pass.

    Of course, objectively defining progress requires work and measuring progress against those definitions takes work, both of which reduce resources available to development. Projects with talented and trustworthy developers will always be more economical than projects with development teams requiring more oversight. (Projects with teams requiring oversight that don’t get oversight will be the worst of all.)

  12. Daniel

    Said on September 10, 2008 :

    I think LOC is good- just not as a “measure of progress”. For example, reducing LOC in a project can be a good thing if you keep the same features – it means your code is more efficient. But you’ll never know if you’re not measuring LOC.

  13. Jeff

    Said on September 10, 2008 :

    A point that has been missed here, IMO, is that once a developer knows his/her lines of code are being scrutinized they will intentionally write code that is more verbose.

    For example, I can use C#’s ternary operator and use one line of code or I can use an if…else block and expand that same evaluation to at least 8 lines. I can make use of automatic properties and have an entire property declaration on a single line or I can break it out into a private member variable plus the individual get/set blocks for several more lines of code. Hell, I might even throw in some additional uneeded validation code for good measure and for at least 2 or 3 more lines. Finally, counting lines discourages good refactoring practices.

    Another thing to consider is that more lines of code is not necessarily a good thing. In many cases this is just code bloat.

    So what happens when developers start adding more lines to ensure they’re being “productive”? Well, they increase the cyclomatic complexity of the methods they write which makes maintenance more difficult, which leads to delays and new bugs, which comes down to more development time and more cost to the company.

    Sorry, Nikki, but in software development “size” is not an indicator of productivity. When you compare it to your ‘miles’ analogy you’re truly missing the point. In development, you can usually say that smaller is better. You could also say that when driving, finding the shortest path to your destination and reducing your miles will actually get you there faster and reduce your gas costs.

    Sorry, guys, but using lines of code as a productivity metric just doesn’t wash.

  14. Bart Czernicki

    Said on September 11, 2008 :

    I don’t know how many of u have designed a Business Intelligence application, but there are multiple approaches to this. Some users want to see the relevant metrics that deliver “true” insight. For example, say you are tracking 5 metrics that measure developer productivity. The user then picks only 2 out of the 5, because they are the most relevant to them how they run the business.

    However, there is also the approach of “just report the numbers” and allowing the users (more hands on) mining or drilling into their own data. For example, manager logs into his portal and sees that Developer A wrote 125 lines of code in the last 2 months..he can drill in and find out why for himself.

    If someone asked me today to write a business intelligence portal for development management. You better believe SLOC would be a metric that I would track. It is easy to understand (I disagree with all the semantics) and think its easy to justify why or why not someone is productive. Integrating that metric with say a time entry system to see how the LOC measure against current projects wouldn’t be hard.

  15. Monty

    Said on September 11, 2008 :

    In my last place of work, the boss there had the great idea of measuring performance by lines of code, till I started screwing with his statistics. Id go around and refactor his work, and by the end of the week, his automated program said I did -300 lines of code!

  16. Andre Lombard

    Said on September 13, 2008 :

    I just recently finished a 6 week development task that added a huge chunk of functionality to an application. My progress was -17000 lines of code! This is just under half of the original size. The app is now more modular and easier for a new developer on the team to understand.

    I agree with Jeff’s cyclomatic complexity comment. A good tool to measure this is NDepend.

    For counting lines of code, I can recommend http://www.locmetrics.com/ (it is _very_ fast) and it will give you various metrics (like logical lines, which exclude white space and comments).

  17. Chris

    Said on September 13, 2008 :

    The reason any manager should want to measure any type of performance is to help Developer see his progress.
    Manager need to be carefull that they are not measure activity but results.

  18. Will Asrari

    Said on September 25, 2008 :

    @skitzo lol

    I hope I never work for a shop that measures progress / success by LOC.

    As a matter of fact, if I were a manager hiring people based on developing a sample application that adhered to specific guidelines I’d take the one-liner aka the programmer with the most succinct source code over a verbose programmer any day.


    if (foo)
    bar = “1”;
    bar = “2”;


    bar = foo ? “1” : “2”;

    b all day for me

  19. Tom Walton

    Said on January 13, 2009 :

    The basic problem with the article is that it assumes that the metric will be used to measure the productivity of individuals. If this happens, you can kiss the metric goodbye. If any individual feels that rewards and punishments are being distributed on the basis of the metrics, then they will game the metrics to make themselves look good. The metrics will become worthless.
    Lines of Code is a good metric for normalization and for estimation, assuming that common sense is used(you can’t add lines of assembler to lines of Perl). The most useful numbers are the new and deleted lines. For small bits of code, this information can be used to plan verification effort (inspections and tests). For example, if a 10000 line file has been modified by removing 100 lines and adding 150 lines, the amount of effort that is needed to reinspect and retest this file should be more closely related to the 250 lines of changes than to the 10050 lines of the total file. Other calculations such as defect density, verification speed are useful. Lines of code produced vs lines inspected or unit tested is also a useful measure. Check out http://www.thedreaming.org/~tomw for more on metrics, many of which are related to lines of code.

  20. Chris

    Said on October 7, 2010 :

    On average, a programmer writes ten to one hundred lines per day, incl. debugging and database.

1 Trackback(s)

  1. Sep 10, 2008: Dew Drop - September 10, 2008 | Alvin Ashcraft's Morning Dew

Post a Comment