Experienced programmers and lines of code

I heard of a study recently that concluded inexperienced and experienced programmers write about the same number of lines of code per day. The difference is that experienced programmers keep more of those lines of code, making steady progress toward a goal. Less experienced programmers write large chunks of code only to rip them out and rewrite the same chunk many times until the code appears to work. Or instead of ripping out the code, they debug for days on end, changing one or two lines at a time, almost at random, until the code appears to work.

As Greg Wilson pointed out in his interview, focusing on quality in software development often results in increased productivity as well. More effort goes into forward progress and less goes into re-work.

Not only do experienced programmers produce more lines of code worth keeping each day, they also accomplish more per line of code, sometimes dramatically more. But that’s not news. It’s well known that the best programmers aren’t just a little more productive than average, they’re one or two orders of magnitude more productive. (See, for example, Joel Spolsky’s book Smart and Gets Things Done.) More interesting is that the best programmers don’t seem to have a much larger capacity for producing and understanding lines of code.

There have also been studies that show programmers produce about the same number of lines of code per day independent of the language they use. You might think that someone working in assembly language could produce more lines of per day than someone writing in a higher level language such as VB or Java, but that’s not the case. It seems that while counting lines of code is a terrible way to measure productivity, it is a good way to measure what you can expect someone to be able to hold in their head.

20 thoughts on “Experienced programmers and lines of code

  1. Great article and I concur.
    re: “Less experienced programmers write large chunks of code only to rip them out and rewrite the same chunk many times until the code appears to work. Or instead of ripping out the code, they debug for days on end, changing one or two lines at a time, almost at random, until the code appears to work”
    So the proper metric appears to be NUMBER OF ORIGINAL LINES OF CODE per day…iow good programmers write correctly the first time. This provides better stability and high quality.

  2. What about agile development where you wrote loads of code then refactor alot. And TDD/BDD style? You write loads of tests/specs before even any functional code. That doesn’t fit. And i really think you need to be an experienced programmer to be good in agile methodology.

  3. As someone who has been writing code for 30 years now, I can say very strongly that there is no comparability of the code I write with, say, someone who has only been writing code for 2 or 3 years.

    I strive for clarity and succinctness in my code, as well as clean structures and object models to better reflect the problems at hand. I’ve written everything from operating systems to drivers to applications, middleware, and web apps.

    It’s not just the code, but the algorithms, patterns, and data structures. One less experienced may not be as comfortable with certain algorithmic approaches, and may choose a brute-force method instead of something more elegant and time-saving.

    But counting lines of code would miss all of this. It’s a silly idea at best. Do comments count as lines of code? Sometimes my comments are longer than the code itself, because I will go into as much detail as I need, so if I walk away for 6 months I’ll know what I had in mind.

    True Productivity cannot be measured easily or quickly. You must include the business model at some point. How much overall time was saved, how much money was saved or made, how much maintenance or downtime was involved, what was the load on Customer Service, etc. These all become factors in True Productivity, and you can chuck the number of lines out the window.

  4. Once, just for fun, I wrote a script that looked through the version control repository and pulled out the number of new lines of code per day. I was the sole developer, and the line count was a brute force thing that just measured the number of lines in a file. What surprised me was that over a six month period, starting from zero lines of code through to a 40,000 line working app, the number of new lines per day was roughly _linear_ the whole time. We hired a new programmer to help, and the total number of new lines per day went _down_ by about 10%.

    So sometimes lines per day is an interesting measure of programmer productivity (contrary to Freds statement above). We were using Extreme Programming, so had other measures like Velocity which is much more customer focussed. Maybe this was a special case?

  5. A recent Usenet post I saw made an interesting point on this subject. It said it takes about three times as long not to write a line of code as to write one. So for example, doing something in 100 lines of APL might take a week. Doing it in 50 lines of APL might well take two weeks, so writing the 50 lines took 0.5 weeks, and not writing the other 50 lines took 1.5 weeks. The fact that programming can produce anomalies like this makes trying to measure programmer productivity a real black art. How do you handle it when the very best programmers can improve your software by producing negative LoC? :-)

  6. I know this is slightly taking the point off topic, but I really don’t think that lines of code by itself is good metric for measuring productivity towards completeness. LOC simply indicates how big the program is or how far along into the job has to go. In a way lines of code is the input and the output are the bugs that have to be dealt with which as you may know from Mythical Man can take up more of the time than anything else. The defects found at unit testing, integration testing, and system testing are the other telling factors on the quality of the code and of the programmer at their job. In a nutshell, I agree with the original premise.

  7. I agree that LOC doesn’t measure progress. I don’t think it’s completely useless. It’s correlated with some interesting things, but doesn’t mean too much by itself. Sometimes you have to take it with a large grain of salt.

  8. Thinking about it a bit more, a good measure of quality and performance could be a ratio of defects per lines of code. That way its normalized to compare developers of all experiences and speed. Though I wouldn’t want to communicate the result to my bosses that I’m operating at .01 “efficiency” so maybe subtract from 1 and turn it into a percentage so 99% would be a better number to brag about. Throw in lines of code with this number and that is an even better indication of both speed and quality. There is a little more rigor on the process for this kind of metric, so I’m not sure I would see it outside of government contractors, though I wonder.

  9. In agile development, in the means described by Eimantas, where refactoring is big part of process a experienced, talented coder can write more finished quality code from the beginning, and produces way higher quality end result.

    Sometimes even inexperienced coders produce easy to maintain, easy to read code, but they don’t usually function straight away, despite them thinking so, an experienced coder gets the functionality right in the first place, therefore, less time to spent on bug hunting.

    But we have to remember that coder has to have the insight to produce a nicely written, easy to read and understand code, structured well. Many, even exceptionally skilled otherwise, lack this fundamental understanding. Way too often i’m hearing the excuse of “it works, and there’s nothing wrong in using 4 function in single line, and if you don’t know what that very obscure, unknown function does RTFM”.

    Writing as few lines as possible is the worst excuse ever for complicated code.

    And yes, someone writing short, easy-to-understand lines of code will produce actually more lines aswell, the difference comes from bug squashing time -> simpler code, easier to identify problems.

  10. John is absolutely correct, LOC is very very bad measurement of progress.

    You can do amazingly a lot with amazingly few lines, while still having easy to understand, simple code, in a bigger more complex system where you can re-use your methods a lot of times, with a good hierarchy and design on the system.

  11. Most useful metrics include language “efficiency” along with SLOC in determing productivity. Look at iEstimator, in iPhone store (better version out soon), to see how these factors are used to estimate software project durations.

  12. We can confirm that:
    1. If a programmer does not write/read/study so many line of code, he won’t be a good programmer.
    2. If a programmer does write/read/study so many line of code, it is still not sure that he will be a good programmer.

  13. Experience comes after having experience. Experienced programmer are not born as programmer but are after several times experiencing failure, writing not necessary codes etc which in fact are the principals of learning. No one can claim is an experienced programmer while this attribute, experienced, is unmeasurable in definition.
    Cheers,
    Developer

  14. Am I the only one who thinks this “agile development” buzzword is a waste of time?

    FYI you did not invent agility. The cave man sharpening his stick knows as much about process refinement as your “agile” buds.

    Same goes for “pivots” and “build measure learn” loops. Do you think you’re the first person to discover a dictionary? I dare you to build anything WITHOUT process refinement.

    To all “agile” aristocrats: I would be more impressed if you told me you could function for 5 minutes without learning anything, without pivoting, without build-measure-learn looping.

    In other words, non-agile development is impossible. That’s why it’s called “development.”

  15. “More interesting is that the best programmers don’t seem to have a much larger capacity for producing and understanding lines of code.”

    John, do you have a reference for this? Thanks!

  16. b: I’ve seen that several places, but I don’t recall a reference. You might find it in Code Complete by Steve McConnell.

  17. I agree. I’ve made similar observations over the years. In the beginning I had a high throughput of code and generated little value. Now I write several times less code but most of it (>95%) stays. That’s what brings experience.

    On a side note, I find it laughable and very unfortunate that the common perception labels aged programmers as slow compared to their younger colleagues. With experience your efficiency (code kept/code written) jumps several times of magnitude. In software engineering the only usable metric is the result, which experienced programmers produce in larger quantities even if with less lines of code.

  18. JOSE NALDRIX D. RIVERA

    What makes the code longer is that the chunks being put in the source code. If your not good at object-oriented programming you will tend to repeat the coding with same algorithms. LOC is very vital in program speed and performance. Having a code that is not repetitive is a sign of good coder.

  19. Jake Rodriguez Pomperada

    For me, the line of code is not a measurement of programmers productivity it is how efficient the algorithm being used in the development of the program. Most often experienced programmers tend to write more code because they were not able to define the right algorithm to solve the problem of their program. The second reason they more concern about the design and looks of their program rather than it’s functionality. The shorter the line of code more efficient the program in terms of speed and execution.
    In the end, the user is the one who will be using the program they don’t care what language you use or how many lines of codes you wrote in order to solve the problem. All they wanted is a program to solve their needs especially in the organization they are connected with.

Comments are closed.