In the 1975 software project management book, The Mythical Man Month: Essays on Software Engineering, Fred Brooks states that, no matter the programming language chosen, a professional developer will write an average 10 lines of code (LoC) per day.

Productivities in [the] range of 600-800 debugged instructions per man-year were experienced by control program groups. Productivities in the [range of] 2000-3000 debugged instructions per man-year were achieved by [OS/360] language translator groups. These include planning done by the group, coding component test, system test, and some support activities.

-Page 93 of "The Mythical Man Month" (1975)

The book quotes other numbers too for other projects, saying e.g. that an O/S is more complicated and therefore slower to write than other types of software. However, a 2000 statements/year figure is virtually identical to the often-claimed 10 LoC/day. Further, it is on the nearly same page as the other part of the claim, which is that LoC/day seems independent of the programming language being used.

Productivity [in LoC] seems constant [across languages] in terms of elementary statements [so it's better to use a higher-level language if you can], a conclusion that is reasonable in terms of the thought a statement requires and the errors it may include.11

-Page 94 of "The Mythical Man Month" (1975)

This claim is still being made today (in 2006, at least). From Jeff Atwood's blog, Coding Horror:

Project Size         Lines of code (per year)     COCOMO average
    10,000 LOC           2,000 - 25,000               3,200
   100,000 LOC           1,000 - 20,000               2,600
 1,000,000 LOC             700 - 10,000               2,000
10,000,000 LOC             300 -  5,000               1,600

The COCOMO averages divided across 250 work days per year results in 6.4 to 12.8 LoC/day, encompassing the 10 LoC/day claim from the 1975 book.

Is it true that professional programmers produce code at around 10 LoC/day?

  • 3
    I had quick search through the book. I cannot find any claim of this form. He does reference some studies of lines-per-year. Please include a quote of the claim from the book, so we are not targeting a strawman. As this is going to attract poor answers before this is resolved, I am putting on hold.
    – Oddthinking
    Commented Aug 6, 2013 at 10:28
  • 3
    There's a lot of data on this subject, with references, in amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/… I don't have my copy of that book with me, but I copied the following data from it two years ago: For a project whose size is between 1000 and 100,000 lines of code, expect from 400 to 833 lines of code per month. Effort varies non-linearly with project size and complexity, but 400 LOC/month is in the same ballpark as 10 LOC/day. Note that this estimate of average LOC/day includes the project's non-coding activities, for example ...
    – ChrisW
    Commented Aug 6, 2013 at 10:59
  • 2
    The question now has appropriate quotes for notability. Thank you. Let's take the rest of the discussion about notability demands to chat or meta.
    – Oddthinking
    Commented Aug 6, 2013 at 13:20
  • 3
    @DJClayworth The 'seminal book' was first published in 1975. IMO a good answer would say whether the quoted metric is still true today, and state the sources of the (more recent) data, instead of simply 'appealing to authority'.
    – ChrisW
    Commented Aug 6, 2013 at 15:29
  • 9
    @user357320 You're forgetting to factor in the lines that are written but don't make it to the final product. When programming a project I could very easily wind up writing 300 lines of code in the space of two hours, then spend the rest of the week and next week debugging, tweaking, yelling at the compiler, realizing that two of the functions I'd originally written won't actually work, then erase half of them and restructure the rest into something that /does/ work. End result: two weeks of work, 150 lines of code. Commented Aug 9, 2013 at 13:06

3 Answers 3


According to Capers Jones, productivity across programming languages is not as constant as the claim, but the evidence supports the claim "it's better to use a higher-level language if you can." As you note in your question, productivity varies dramatically depending on project size, so it's probably not helpful to try to pin down "average LoC / engineer / month" averaged across all different project sizes. But for projects of similar size...

The following tables from "The Economics of Software Quality" show productivity on 10 PBX systems of approximately the same size:

None of the projects were exactly 1,500 function points in size, and the original sizes ranged from about 1,300 to 1,750 function points in size. Here, too, the data normalization feature was used to make all 10 versions identical in factors that would conceal the underlying similarities of the examples. -- Capers Jones; Olivier Bonsignour. The Economics of Software Quality (Kindle Locations 2251-2253). Addison-Wesley Professional. Published 2011.

enter image description here

The data show Lines-of-Code productivity decreasing in higher-level languages (ranging from 480 LoC/Developer-Month with Assembly to 162 LoC/Developer-Month with Smalltalk) but Function Point productivity increasing with higher-level languages (1.92 FP / Developer-Month with Assembly to 7.71 FP / Developer-Month with Smalltalk). This is a chart of the data:


  • 10
    Not too many modern languages on the list. It was published 2011, but when was the research data collected? 80s-90s?
    – vartec
    Commented Aug 7, 2013 at 6:42
  • 5
    Jones has been collecting his productivity stuff since the 80s, and it's ongoing. I agree that a lot of his analysis shows a strong lead-time effect, but I think his methodology is very well established and for the purposes of the question, appropriate. While I'd be interested in seeing how Erlang, Clojure, and F# stack up, I don't doubt they'd support the "lower LoC productivity, higher FP productivity" result the charts show. Commented Aug 7, 2013 at 17:31
  • 1
    @LarryOBrien, great data, and it would be nice to see some more with other languages as vartec pointed out. Also, it would be great if you could give a brief summary of the data like, "assuming an 8 hour day, the LOC metric ranged from 9.84 for Smalltalk to 27.04 for Assembly. The data also shows that the LOC productivity metric strongly depends on the language..." Commented Aug 8, 2013 at 2:26
  • 8
    Strange that there's Ada95 (which I've never heard of anyone actually using) and "CHILL" (which I've never even heard of), but none the more popular "modern" languages like Python, Ruby, C#, or Java (or Erlang, which I hear is widely used in PBX now); and none of the outdated-but-still-widely-used-in-legacy-applications languages like COBOL, RPG, and JCL... And "Assembly" isn't even one language. I get the strong impression that this data was cherry-picked to make the graph work. Commented Aug 9, 2013 at 22:44
  • 5
    Well... Jones started his company Software Productivity Research in 1984 (en.wikipedia.org/wiki/Capers_Jones), literally wrote the book(s) on software economics, and is published and cited regularly throughout ACM and IEEE. His data shouldn't be dismissed breezily. CHILL, for instance, was an important telecom language in the 80s and 90s and has an ISO standard -- it's not at all suspicious to see it in a list of languages used to implement a substantial (15 years of effort) PBX system. Commented Aug 10, 2013 at 19:12

The 2nd edition of Code Complete cites Cusumano et al. (2003) for the best-known (till then) industry figure(s). The paper is based on a survey of 104 projects in four regions of the globe. The authors' LOC/productivity summary is in the table below.

enter image description here

The wide variance does raise an eyebrow, which the authors attribute to different characteristics of the projects in a rather undetailed manner, but they also to posit that

US programmers often have different objectives and development styles. They tend to emphasize shorter or more innovative programs and spend more time optimizing code, which ultimately reduces the number of LOC and increases effort.

There's substantial data on project characteristics in the paper (two tables: one for area/requirements/platform/customer and one for the development practices involved; both tables are a bit large to reproduce here), but the authors did not conduct any regression analysis to test if any of the characteristics explain the variance in a statistically significant way... for this sample (and in this paper). They did do something like that in a companion paper for a smaller/pilot [sub-]sample of 29 US projects:

enter image description here

The regression model was (alas) obtained by stepwise backward procedure. There is obvious multicollinearity going on since the daily builds became explanatory/significant in the final regression but having a functional specification was no longer explanatory.

Also the same (companion) paper on the (29) US projects reported some more detailed descriptive statistics on productivity (mean 26.4 LOC/day, median 17.6):

enter image description here

There's some obvious distribution asymmetry to be inferred from the non-parametric skew here, but the actual sample skewness cannot be calculated just from they summary they reported. Annoyingly, the inclusion of two extra US projects in the first paper mentioned makes it risky to compare the median outputs: 270/17.6 gives us 15.34 working days per month, which probably means a different project was selected as median in the two papers/samples.

Some newer data is reported in the DoD Software Factbook v1.1 (sample of 208 projects from 2004 to 2011, but most were from 2008 to 2010)

Their results:

• real-time software 12.2 PM per KESLOC

• engineering software 8.8 PM per KESLOC

• mission support software 5.1 PM per KESLOC

• automated information system 2.8 PM per KESLOC

PM = person month, ESLOC = equivalent source line of code, which is however higher that simply new SLOC, because it also adds modified SLOC, reused SLOC, and auto-generated SLOC, each of these three adjusted with a certain (subunitary) factor. (And 1 KESLOC = 1,000 ESLOC.)

This is based on a log-log regression with the plot below:

enter image description here

The black vertical line in the graph corresponds to an "average" project of 25 KESLOC. This is not a true average even for log-transformed data (which is much closer to normality), but a reasonable approximation (averaging in log-units corresponds to 23,442 ESLOC and the median is 28,840 ESLOC).

Using the mythical 20.8 working days per month, the DoD numbers translate to 3.94 ESLOC/day (RT software) to 17.17 ESLOC/day ("automated information system"), with the in-between figures of 5.46 ESLOC/day for engineering software and 9.42 ESLOC/day for "mission support".

  • In that top table, the formula for "median output¹) is wrong, unless their "no of programmer-months" is actually average per staff—if they actually used that formula, the number is meaningless.
    – Kevin
    Commented Dec 13, 2017 at 18:06
  • @Nat: I tried to do that. Hopefully my math isn't wrong. Commented Dec 13, 2017 at 19:30
  • 1
    Looks good to me! Might want to consider a short summary at the top, for a less-technical perspective.
    – Nat
    Commented Dec 13, 2017 at 19:33
  • 1
    I have to agree with the short summary. There is a lot of technical information and acronyms to wade through. A conclusion paragraph that restates the claim in terms ESLOC/day would be helpful. Commented Dec 13, 2017 at 19:44
  • 1
    Number of defects should probably be "number of reported/identified defects" which are very different and a subject for many factors including how the defects are counted and acquired. Commented Dec 13, 2017 at 20:39

To understand what you're asking, you have to contrast the software situation in 1975 with that of today.

In 1975, you would probably be writing in COBOL on an IBM 360. The input/output situation was very simple: text based displays, printers, and either disc or punch card data sources. Because everyone was writing essentially the same code, the same way, performing very simple tasks, lines of code per day/month/year might have been an applicable measure, although there are still defects and how well the solution addressed the need to consider.

Given the verbosity of COBOL to accomplish even the simplest task, I'd say the 10 lines of code per day sounds low. 10 lines of COBOL code won't even describe one input record.

Today, in 2017, the situation is far more complex. In 1975, most people never got near a computer terminal, and the few that did had a text display connected to a single mainframe. Today, everyone has a computer in their pocket, with a full graphical user interface, connected to the world.

The efficiency of a developer today is more determined by the system and platforms they are using, than how many lines of code they turn out. On a simple level, a web app system like PHP takes far fewer lines of code than a complex web app system like ASP.NET or JSP. Because it's simpler, a developer can produce more lines of code per day. However, as the complexity of the task rises, PHP may not be able to deliver the functionality. It's not efficient if it can't meet the need and your project ends up as a failure.

Unlike 1975, when no one was ever fired for buying IBM, today you can choose a system and platform that looks good by simple metrics, but ends up failing to deliver the functionality needed. Can't be scaled up to meet the need, can't be secured, can't be quickly updated, etc...

Also consider that in 1975, the concept of reusable blocks of code... as in objects and lately web services, didn't exist. There was a lot of duplication of effort back then, that simply doesn't happen today. How may lines of code per day did a developer produce when they reused a known tested web service as a source, rather than rolling that from scratch? Instead of 1000 lines of code, they produced one line of code to call the service, so lines of code per day paints a very misleading picture in that regard.

Lines of code per day might have been applicable in 1975, because everyone was using the same method, performing the same simple tasks. In 2017, the situation is far more diverse, and far more complex. It's like judging a 787 airliner by Wright Flyer metrics, concluding the 787 isn't very good because it it only has one set of wings instead of two.

So to answer your question... it can't be answered because lines of code per day isn't worth establishing in the 2017 computing environment.

  • There are so many inaccuracies in this that I don't know where to begin. (But, for starters, in 1975 I was writing in assembler for an IBM 5100. On an IBM 2260 video terminal.) Commented Dec 21, 2017 at 19:40
  • Please enlighten me... COBOL was the typical language, though assembler was used - my older brother was a lead developer on CICS, written in assembler. As I recall, assembler could be horridly inefficient to write. 200 lines of assembler might translate to one complex COBOL command, so lines of code per day would be very inaccurate... one might conclude that an assembler programmer was 'more efficient' because they turned out more lines of code.
    – tj1000
    Commented Dec 21, 2017 at 19:57
  • If you look at the answer from Larry O Brien, developer productivity is roughly equal across a range of languages (within about a factor of two, which is about as accurate as such measures can be). Yes, some measures make C++ more efficient than assembler, but this often fails to take into account the complexities (eg, writing kernel code) which drove the choice of assembler over C++ in the first place. And the main reason why the numbers come out as close as they do is that writing the code is the easy part. The time goes into design, debug, documentation, et al. Commented Dec 21, 2017 at 20:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .