Mythical man month : 10 lines per developer day

The mythical book, Mythical man month quoted that no matter the programming language chosen, a professional developer will write in average 10 lines of code (LoC) day.

After a bit more than 6 years of full-time development on the tool NDepend I’d like to elaborate a bit here.

Let’s start with the definition of logical Line of Code. Basically, a logical LoC is a PDB sequence point except sequence points corresponding to opening and closing method brace. So here we have a 8 logical lines of code method for example:

See here the post How do you count your number of Lines Of Code (LOC) ? for more details.

I already hear the bashing; LoC has nothing to do with productivity, Bill Gates said “Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.“.

And indeed, measured on a few days or a few weeks range, LoC has nothing to do with productivity. Some days I write 200 LoC in a row, some days I spend 8 hours fixing a pesky bug by not even adding a LoC. Some day I clean dead code and remove some LoC. Some other days I refactor exiting code without, all in all, adding a single LoC. Some days I create a large and complex UI Form and the editor will generate automatically 300 additional LoC. Some days are dedicated solely to performance enhancement or planning upcoming code architecture…

What is interesting is the average number of LoC obtained from the long term. And if I do the simple math I obtained around 80 LoC per day. Let’s precise that I abide by high code quality standard. Each LoC must be covered by unit-tests + all possible code contracts must be declared (of course, not all LoC can, nor should, be checked by contracts and some classes are nit relevant for unit-testing, especially UI related classes).

So this average score of 80 LoC produced per day doesn’t sacrifice to code quality, and seems to be a sustainable rhythm. And what is really cool with LoC, is that, once calibrated, caring about counting LoC becomes an accurate estimation tool. After coding and measuring dozens of features achieved in this particular context of development, the size of any feature can be estimated accurately in terms of LoC. Hence with a simple math, the time it’ll take to deliver a feature to production can be accurately estimated. To illustrate this fact, here is a decorated treemap view of most NDepend components.

Thanks to this treemap view, I can compare the size in terms of LoC of most components. Coupling this information with the fact that the average coding score if 80 LoC per day, and looking back on cost in times for each component, I have an accurate method to tune my way of coding and estimate future schedules.

Of course not all components are equals. Most of them are the result of a long evolutive coding process. For example, the code model had undergone much more refactoring since the beginning than say, the dependency graph for example that had been delivered out-of-the-box after some weeks of development.

There is something else interesting this picture is telling. I can see that all these years polishing the tool to meet high professional standards in terms of ergonomy and performance, consumed actually the bulk of LoC. For example just having a clean Project Properties management is implemented through (model + UI control) =(3.751+2.686) = 6.437 LoC. While a flagship feature such as the interactive Dependency Graph only consumes 2.897 LoC, not even a half of the Project Properties impelmentation. Of course the interactive Dependency Graph capitalize a lot on all the existing infrastructure developed for other features. But as a matter of fact, it took less effort to develop  the interactive Dependency Graph than to develop a clean Project Properties model and UI.

All this confirms an essential lesson for everyone that wishes to start an ISV. It is lightweight and easy to develop a nice and flashy prototype application that’ll bring enthusiast users. What is really costly is to transform it into something usable, stable, clean, fast with all possible ergonomy candy to make the life of the user easier. And these are all these non-functional requirements that will make the difference between a product used by a few dozens of enthusiast users only, and a product used by the mass.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Greg

    I’ve always found discussion about predictive estimating based on previous results to be valuable, whether you are talking LOC, user stories, function points, etc.  Anything historical that you can use to guide your estimate of the parts is helpful.  One degree of inaccuracy in estimates multiplies when you add the pieces up. 

    What I find interestingly missing, given the amount of time and mental labor you and others spend on fixing Programming, is discussion on the one key variable for your estimates — task definition and design!  If you get a vague spec, I don’t care how accurate your history is, you will end up with a bad estimate.  Poor specs, inaccurate design, poor architecture — these are the things that really kill a project, and they are very difficult to allow for in an estimate.  The time we spend analyzing our historical results, figuring out what is a reasonable estimate for an upcoming task, adding whatever fudge factor you think is right…it really would be far less necessary if that time was spent up front making sure specs are complete and accurate.  Why is it always Programming that appears to need fixing?

    Perhaps your situation provides nice specs, so you can spend the time refining a Programming estimate…and I thoroughly enjoyed your article and your insight there and in the comments…but I would bet most people will not be able to resort to simple math to accurately estimate projects until Design does their job properly. 

  • psmacchia

    >Every line of code you write today is going to cost more in maintenance than in creation.

    On the wordd “Every” and “is going to cost more” I fundamentally disagree.

    Concerning “Every”, I agree that, for every LoC written, it is not possible to forecast ** if and when ** it will have to be refactored.
    But experience shows that, if the code base structure is sufficiently well decoupled, ** most ** of existing LoC shouldn’t change any time near.

    Concerning “is going to cost more”, if high code quality standard has been applied in the first place (LoC covered by tests, LoC framed with appropriate code contracts…), the cost of its eventual refactoring and maintenance is pretty low.

    >if we have – a developer’s got a good idea and he can get something done in 4K-LOCs instead of 20K-LOCs, should we make less money?

    If the 20K LoC logic can be shrink into a 4KLoC logic, I’d say that the developer responsible for the 20K LoC is lyer or (not exclusive) incompetent. In both cases, it is not someone I’d like to work with.

    >Lines of Code is a dead metric for productivity. 

    It is clear that ** in the long term ** more features necessarily means more LoC.

    Whether we are talking of 10, 80 or 200 LoC written a day, more LoC means more features, and means productivity, in the long term. I don’t omit maintenance, but maintenance is part of the development process ** in the long term **.

    What I say in the post, is that once measured ** in the long term and in a constant development environment**, LoC is a solid and predictable metric to base estimation and productivity assessment on.

    I often repeat ** in the long term ** and ** in constant 
    development environment ** because everything stated here, deosn’t hold in the short term or with a changing 
    development environment .

  • Edwin Buck

    If we wish to count lines of code, we should not regard them as “lines
    produced” but as “lines spent”.
    – Edsger Dijkstra

    The life of software goes far beyond creation.  Every line of code you write today is going to cost more in maintenance than in creation.  Proving productivity by showing that you can crank out more lines of code than some arbitrary standard is a poor practice indeed.

    Selective reading (and selective support) of an idea can give one a very skewed view of the field.  Lines of Code is a dead metric for productivity.  It was borne out of the illogical notion that we have such a hard time measuring productivity, that we should measure what is obvious and then attempt to correlate that to productivity. 

    Here’s an insight as to why LOC is still so dominant in people’s minds today (from Steve Ballmer).  It has nothing to do with value, but everything to do with how poorly businesses know how to value software, basically it breaks down to price bickering.

    In IBM there’s a religion in software that says you have to count
    K-LOCs, and a K-LOC is a thousand lines of code. How big a project is
    it? Oh, it’s sort of a 10K-LOC project. This is a 20K-LOCer. And this is
    50K-LOCs. And IBM wanted to sort of make it the religion about how we
    got paid. How much money we made off OS/2, how much
    they did. How many K-LOCs did you do? And we kept trying to convince
    them – hey, if we have – a developer’s got a good idea and he can get
    something done in 4K-LOCs instead of 20K-LOCs, should we make less
    money? Because he’s made something smaller and faster, less K-LOC.
    K-LOCs, K-LOCs, that’s the methodology. Ugh! Anyway, that always makes
    my back just crinkle up at the thought of the whole thing. – Steve Ballmer

  • http://www.facebook.com/chasrmartin Charlie Martin

    You’re missing a couple things about the history of the “lines of code” metric and its definition.

    First, 10 LOC/staff-day is the mean *but* it’s well-known that individuals vary by an order of magnitude, even on similar problems.  

    Second, 10 LOC/staff-day is for the average for delivered and documented code, so it’s not just coding time.  In the old days, coding was expected to account for about 15 percent of total effort, so we’d get 85 * 0.15 = 12.75 as the apple-apples comparison.  That’s *well* within 1 sigma.

    That said, you’ve got good points: first, LOC isn’t all that bad a volume measure, and second yes, you can make decent predictions using it.

    You might look at Watts Humphries’ Personal Software Process for a very detailed exploration of this stuff.

    http://en.wikipedia.org/wiki/Personal_Software_Process

  • http://www.itoctopus.com/ itoctopus

    Am I the only one who thinks that Bill Gates’ quote doesn’t make sense at all – there is no such thing called “progress” on an airplane.

    I understand that he wanted to mean that lines of codes are irrelevant to productivity, but again, he didn’t say something that makes sense at all…

  • http://weblogs.asp.net/gunnarpeipman/ Me

    NDepend visualizes usually projects in solution very nicely and that helps to get also visual overview of past projects we can use to estimate new ones. Important point is – if you don’t have VS projects with well separated responsibilities then LoC is not very accurate. If projects in solution have responsibilities set well then LoC + NDepend is very helpful to also get better picture about “size” of projects.
     
    Of course, you cannot take it as absolute truth but it makes estimates better.

  • Anonymous

    I think your article is very good and I hope you don’t mind my attempt at injecting a little humour :-)

    You must admit my friend that your typical day is peppered with colleagues wanting to discuss the latest happenings in last nights soap opera/sports event, when all you really want to do is write some code?

    I think every developer should read Code Complete by Steve McConnell, it’s great for improving your coding.

  • Patrick Baggett

    Interesting. I wonder if this accounts for the functionality of some open source projects and yet the seemingly unpolished interfaces or workflows. I imagine the cost-benefit of making a tool that scratches something other than your own itch is less enticing.

  • psmacchia

    Indeed, the
    fact that a good portion of the effort goes into non-functional requirements that
    make the software mature and sellable, and that the remaining effort goes into
    feature development, can be seen as a sort of 80/20 Pareto Law. It is pretty
    interesting to verify this law with numbers on a real-world large code base.

    Concerning
    the lead developer that claims “less talking! more typing!”, that don’t
    want to hear anything about code quality, unit tests, correctness, architecture,
    evolution, estimation … that cannot imagine that there will be some other dev
    after the next dead line, I met a few of them when I was a junior developer. Actually the
    whole NDepend project was an exit door for me from this kind of poor
    development environment :-) 

    And today, since NDepend is all about going meta by
    analyzing facts from the code base, to develop better code with less effort, it is a good part of my job to go meta and by assessing from the facts
    what works and what doesn’t work.

  • Anonymous

    Aren’t you just reinventing the 80/20 rule and the Man Month?

    Maybe you should spend less time on your psuedo science and more time on doing some actual coding, then you might get you “LOC” up to 90 per day :-)

    The first lead developer I ever worked for, use to say “less talking! more typing!”

  • Anonymous

    Thank you for the quick reply and explanations, and again thank you for sharing your insights. I always like to learn about how others do these things and what process and optimizations work for them. 

  • psmacchia

    Peter, you are right, I didn’t stress enough the fact that after developing N features in the same development context …. one got a sense about estimating the size of the upcoming feature(s) to implement, in terms of LoC “bigger” or “smaller” compared to the N features already implemented. Taking account that a bunch of re-usable “helpers” have been developed, or still need to be developed for the upcoming development. The cool thing about helpers, is that after many years of development it gets more and more solid and close to complete.

    This core estimation, usually leads to accurate estimation of the amount of resources to spend in the planned development, being estimated in man-day. This is pretty much the same conclusion than Steve Mc Connel in its mythic Software estimation book http://www.stevemcconnell.com/est.htm. The important thing to stress out is the “context of development” that is considered as a constant. The context includes company policy, team size and level of agility, engineers skills, level of quality, of security…

    Thanks Peter for this insightful comment, that let me elaborate deeper.

  • Peter Kuhn (Mister Goodcat)


    Hence with a simple math, the time it’ll take to deliver
    > a feature to production can be accurately estimated.

    Does it? If I understand you correctly the logic is that with this system estimations can be based on LoC (after “calibrating”, and in this particular context), and since you know the costs for your LoC, your estimations are more accurate. 

    The point with this, and this is where I fail to see the advantage, is how to accurately obtain the LoC you will need to churn out to deliver a certain feature. So, isn’t that just shifting the problem from more traditional ways of estimation to estimating the LoC you need to implement something? Is this really easier for people to do?

    I also believe that you didn’t stress the point enough that “not all components are equal”. Maybe it would work well if you were able to break down the LoC costs to these individual components. But with an average cost equally applied to all components, of different complexity and requirements, I don’t see how you could provide accurate estimations without making adjustments and using your experience in individual areas of the product (I think you can’t just simply use n x 80 LoC and expect accurate results for example for both adding a feature to a UI element and adding one to the core product, right?).

    I do not mean to criticize; it’s just hard for me to share the same conclusions. Anyway, thank you for these nice insights into your findings and thoughts.
    -Peter (@Mister_Goodcat)