An executive at my workplace asked me and my group of developers the question:

How many lines of code can a C# developer produce per month?

An old system was to be ported to C# and he would like this measure as part of the project planning.

From some (apparently creditable) source he had the answer of "10 SLOC/month" but he was not happy with that.

The group agreed that this was nearly impossible to specify because it would depend on a long list of circumstances. But we could tell that the man would not leave (or be very disappointed in us) if we did not come up with an answer suiting him better. So he left with the many times better answer of "10 SLOC/day"

Can this question be answered? (offhand or even with some analysis)

  • 7
    Do those lines need to have any quality embedded? >_> Jan 26, 2011 at 8:21
  • 4
    Can it be computer generated code? If so, I'm pretty sure I can get into the Zetta power prefix (10 ^21) in lines, given the right hardware. It wont do anything, mind you... Jan 26, 2011 at 8:46
  • 6
    Credible source: Mythical Man Month. Jan 26, 2011 at 10:26
  • 2
    How much wood can a woodchuck chuck if a woodchuck could chuck wood? I cannot believe this question is still being asked! What, is this 1975? There are much better questions, like, "How many systems has the development team successfully deployed this year?" or "How many hours per month have been saved using the current system compared to before?" The question should be of value, not quantity of an irrelevant metric. Jan 26, 2011 at 14:10
  • 3
    The question should not be answered because it is based on false assumptions like "more is better" or "more code means more quality".
    – ThomasX
    Mar 28, 2012 at 10:29

16 Answers 16


Ask your executive how many pages of contract his lawyer can write per month. Then (hopefully) he will realize that there's a huge difference between writing a single-page contract and writing a 300-page contract without loopholes and contradictions. Or between writing a new contract and changing an existing one. Or between writing a new contract and translating it to a different language. Or to a different law system. Maybe he'll even agree that "pages of contract per unit of time" is not a very good measure for lawyer productivity.

But to give you some answer to your real question: In my experience, for a new project a few hundred SLOC per day and developer aren't uncommon. But as soon as the first bugs appear, this number will drop sharply.

  • 18
    That number might even drop so sharply as to get into the negative ... Jan 26, 2011 at 10:07
  • It's not a correct analogy. It is perfectly fine to ask a translator of how many pages of an English text he can translate into German in one week. And they're porting an application from one language/platform to another, kinda similar thing to a translation.
    – SK-logic
    Jan 26, 2011 at 12:30
  • 4
    @SK-Logic is it? Try translating a casual conversation, then try translating a long legal document.
    – BlackICE
    Jun 17, 2011 at 15:10
  • @SK-logic - Each line in a translated source document will generally be mapped to a single line in the target document - it's a very linear mapping. When it comes to software, it is unlikely that two programming languages are similar enough in structure and capability to be able to expect the same. There will likely be numerous areas where savings could be made, and some areas, where you will have comparatively more code to write.
    – cjmUK
    Apr 5, 2012 at 14:27
  • 1
    @KristofProvost, a 1-to-1 translation is normally a starting point for a lengthy and painful refactoring process. But it is necessary to get something working first. And in all the translation projects I met, the main motivation was in ageing of the original toolchain (e.g., PL/I to C++) and lack of confidence in its future. Clean and idiomatic code had never been a top priority in such projects.
    – SK-logic
    Nov 21, 2012 at 9:17

How many lines of code can a C# developer produce per month?

If they are good, less than zero.

  • 5
    +1: When maintaining legacy code, we strive for a negative-LOC check-in (while maintaining or improving functionality). One of my colleagues managed to remove 2,500+ lines of code in one check-in. That refactoring took him about a week, but the overall average was still more than -300 lines per day. :-)
    – Peter K.
    Jun 17, 2011 at 15:16
  • Measuring by reduced lines of code is just as meaningless as it falls into the same trap - that number of lines of code is a valid measurement of anything other than number of lines of code. Give me 40,000 lines of good code over 10,000 lines of unreadable, bug-riddled spaghetti any day. Nov 20, 2012 at 10:09
  • 1
    Of course it is meaningless @mh. this is more of a tongue-in-cheek answer Nov 20, 2012 at 15:15

Run the other way... Now.

LoC is one of the worst metrics you can use.

Bad developers can potentially write more LoC a day than good developers, but churn out rubbish code.

Depending on the complexity of the code, porting can be done by automation processes which would result in large thousand+ LoC changes a day, whereas more difficult sections where the language constructs are wildly different code be ported at the 100LoC a day.

Send him to read the Wikipedia page on SLOC. If gives some nice and simple examples of why it is such a poor metric.


The Right Answer : No...

This executive should be educated, that SLOC is not a valid metrics for analysis progress

The Sloppy Answer : Any Number you can make up of.

Just give him some number, you and your team can easily to make that number up anyway. (By putting unless line, empty lines, comments etc etc, just to allow this guy to continue to live in his fantasy world, and haunt yet another team and continue the misery reinforced cycle which makes a story to thedailywtf.

Not nice, but do-able.

  • I would have to say that the comments could increase the usefulness of the code, though.
    – Nitrodist
    Jan 26, 2011 at 8:01
  • 2
    @Nitrodist indeed good comments are, the comments I am referring to is just used to "make" the executive happy. Which would be totally useless...
    – Zekta Chan
    Jan 26, 2011 at 8:08

From the first glance this question looks absolutely stupid, and everyone here answered to the stupid C# LoC part of it only. But there is one important nuance - it's a question about a porting performance. The right way to ask this question is to ask, how many lines of code of the source project (the one being ported) a developer can handle within a given unit of time. It's a perfectly justified question, as the total number of lines of code is known, and it's exactly the amount of work to be done. And the right way to answer this qeustion is to collect a bit of historical data - work for, say, a week, and measure performance of each of the developers.

  • 1
    How is this an indication of the exact amount of work to be done? If you need to port 1000 lines of code, it may be possible to port it to 50 lines of code if available libraries / existing functionality, etc. are used. And it could also take 50 lines to port an existing 100 lines of code as well. Totally dependent on the code. Jan 26, 2011 at 14:14
  • I said that a source number of LoC is a proper metric, not the output.
    – SK-logic
    Jan 26, 2011 at 14:16
  • 2
    I disagree. If sections of code exist in the original that make no sense in the port, then they are never considered 'ported' and hence, never counted. OTOH, creating a feature and support set for the original can give a more meaningful indication of progress-to-completion. Simply put, the progress metric is only worth the effort one is willing to put into generating and maintaining it.
    – mummey
    Jan 26, 2011 at 21:07
  • 1
    @mummey, effects you're talking about are just fluctuations, they should disapper on a statistical base large enough.
    – SK-logic
    Jan 27, 2011 at 11:03

I only have one thing to say:

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”

-- Bill Gates

After that, you may argue that Bill Gates didn't know how to make successful software ;)

Note: SLOC is a very good measure of code-base complexity though!


Proportional to the number of words, in fact.

You see my point?

  • 1
    Most tools that generate loc stats give you logical LOCs - ie "code statements" not "editor lines". So your answer would have gotten a score of 1 LLOC. They also generate useful metrics like ratio of comments to code and code complexity, so theyr'e not completely useless.
    – gbjbaanb
    Jun 17, 2011 at 15:32
  • 1
    @gbjbaanb That is just another kind of useless. Declarative languages don't have statements or, therefore, "statement lines". Good code can be self-documenting with sane identifier names instead of comments. Other code is written more graphically where there is no meaningful concept of "lines", e.g. Mathematica notebooks.
    – J D
    Mar 28, 2012 at 9:16

I might have a slightly different stance on this, but I think I might understand why the executive was looking for this information if they are currently doing project planning. Since it is hard to estimate how long a project is going to take, one of the methods that is used (see: Software Estimation: Demystifying the Black Art) is to estimate how long it will take the project on the basis of the number of SLOCs in similar projects and now may the developers produce on average. In practice this is meant to be done using historical records that the group has on hand for similar projects with the same or similar developers.

However, it is worth nothing that these estimates are meant only for basic project planning and aren't actually intended to set the pace of the developers on the project because things change from day to day. Thus, most of what you read on using SLOCs as an estimation tool is that they are good over the long run if you have a good body of knowledge already, but lousy for day to day use.


It is generally a bad idea to call your boss an idiot, so my suggestions start with understanding and discussing metrics, rather than rejecting them.

Some people who are not actually considered idiots have used metrics that were based on lines of code. Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan, and Steve McConnell all used them. You have probably used them even if just to say to a colleague, this God module is 4000 lines, it needs to be broken into smaller classes.

There is specific data related to this question from a source that many of us respect.




I suspect that the best use of line of code per programmer hour is to show that over the life of the project, this value will start pretty high, but as defects are found and fixed, new lines of code will be added to solve problems that were not part of the original estimates, and lines of code removed to eliminate duplication and improve efficiency will show that LOC/hr indicates things other than productivity.

  • When code is written fast, sloppy, bloated, and without any attempt at refactoring, the apparent efficiency will be at its highest. The moral here will be that you must be careful for what you measure.
  • For a particular developer, if they are adding or touching a high quantity of code this week, next week there may be a technical debt to pay in terms of code review, test, debug, and rework.
  • Some developers will work at a more consistent rate of output than others. It may be found that they spend the most time on getting good user stories, turn around very quickly and make corresponding unit tests, and then turn around and quickly make code that is focused on only the user stories. The take away here is that methodical developers will probably have quick turn around, will write compact code, and have low rework because they understand the problem and the solution very well before they start to code. It seems reasonable that they will code less because they code only after they think it through, instead of before and after.
  • When code is evaluated for its defect density, it will be found to be less than uniform. Some code will account for most of the trouble and defects. It will be a candidate for rewriting. When that happens, it will become the most expensive code because by virtue of it high degree of rework. It will have the highest gross lines of code counts (added, deleted, modified, as might be reported from a tool like CVS or SVN), but the lowest net lines of code per hour invested. This may end up being a combination of the code either implementing the most complex problem or the most complicated solution.

Regardless how the debate over programmer productivity in lines of code turns out you will find that you need more man power than you can afford and the system will never be completed in time. You real tools are not metrics. They are use of superior methodology, the best developers you can hire or train, and the control of scope and risk (probably with Agile methods).

  • The take away here is that methodical developers will probably have quick turn around, will write compact code, and have low rework. Disagree. It's either low reword or quick turnaround. Okay, the 3rd option is burn out and leave developer's career. Jan 10, 2017 at 18:51

Give him a better metric to work with

Instead of LOC , explain this is the worst metric to use. Then give him an alternative:

No. of Functions/Features Per Feature/Function Requests -> NOFF/RFF

You may need to add a weighting/normalization on top of NOFF/RFF, to cater for the amounts of requests per week.

:) clearly the above is made up, but anything, is better than SLOC...


I can tell you that a load of contractors for a big project wrote 15000 LOC (each) in a year. That's an incredibly rough answer, but it was useful to us as we have 400,000 existing C++ LoC and we could figure out that converting it all to C# would take us about 26 man-years to complete. Give or take.

So now we know the rough order of magnitude, we can plan better for it - getting 20 devs and estimating a year's work for them all would be about right. Before counting, we didn't have a clue how long it would take to migrate.

So my advice for you is to checkout all the code you've written in a specific amount of time (I was fortunate having a fresh project to work with), then run one of the many code metric tools on it. Divide the number by the time and you can give him an accurate answer - how much LOC you actually write per day. For us, that came out at 90 LOC per day! I guess we did have a lot of meetings and documentation on that project, but then I guess we'll have lots of meetings and documentation on the next one too :)


Sounds about correct.


If you take into account the debugging, documentation, planning etc. It average out at about 10 lines of code per day. Actually I would rate 10 lines a day on the high side (ie a very productive dev).

Even though you can churn out a couple of hundred lines in a single day (this is not sustainable). It not be quality code until you have then added all the unit test the documentation and of course debugged the code after your unit test show the errors. After all that is done you are back to 10.


My guess is, a developer working with a language like C# should be able to write / generate about 10K LoCs / day. I suppose, I could do that. I just never would.

What you want of a developer is, to get his job done in 10 LoCs / day. Less code is always better. I often times start out producing a bulk of code and then cutting away until I reach the bare maximum of simplicity, so I do actually have days with negative LoCs.

In a sense, coding is like poetry. The question is not, how many lines a poet can write, but how much he can convey in the 14 lines of a sonnet.

  • 5
    10K LoC? IMO that can only be done by a generator. As far as handwritten LoC go, I would rather put the upper limit in the range of 1K LoC. And that has to be an execeptionally productive day.
    – user281377
    Jan 26, 2011 at 9:25
  • @ammoQ: It is feasible. If somebody asked you to write as much code as possible, you could do that. It's probably just a myth, but I have heard that programmers forced to produce many LoCs do so by including dead or duplicate code, by expanding loops and inlining functions by hand (or not having loops and subroutines in the first place) and many other stupid things. Also, the overuse of boilerplate code helps :D
    – back2dos
    Jan 26, 2011 at 9:40
  • @back2dos: OK, I was rather thinking about code that actually makes sense.
    – user281377
    Jan 26, 2011 at 10:01
  • @ammoQ: well that's certainly nothing I would blame you for. My point was rather, that metrics, that don't make sense lead to code, that doesn't make sense ;)
    – back2dos
    Jan 26, 2011 at 10:26

Let your manager handle it, or begin job hunting.

In all seriousness, you could spend tim it what may end up being a hopeless endeavor in explaining to the executive the proper and improper methods of measuring a project's progress toward completion. In all reality though, what engineering and project managers are for.

In the other hand, the circumstances are such that the executive-in-question IS your engineering and/or project manager. You have much bigger and more basic issues to deal with, even if they have not yet revealed themselves. In this case an issue like this can serve as a "warning shot" for bigger problems to-come.


Other answers are correct, it's a dumb question and the answer doesn't mean a damn thing. It's all true, but I happen to know how many lines of code I produced in roughly one month.

It's about 3000 lines of C# code without XML-doc. I was implementing new functionality and ended up with this amount in a month or a month and one week. It's all that ended up in source control, a lot of code was written and then refactored or deleted.

I'm a C# developer and I'm trying to be good at it, but I can't tell you how objectively good I am. I tried to write good code and put a lot of effort to make it easy to maintain. I only put comments once or twice in this code.

I don't know wether it's too many or too few lines of code and I have to say I don't really care. It's a meaningless piece of data and it can't be safely used for extrapolation in any way. But I happen to know this data so I decided to share.


Well, I am a bit late to this party as usual, but this is actually an interesting one. I initially had the same thought as most that the executive's question is daft. However, I read SK-logic's answer and came to realize that it is a sensible question asked in a nonsensical way. Or, put differently, there is a valid problem behind the question.

Managers often need to try do determine the feasibility, funding, staffing, etc for a project. This is a sensible problem. For a straightford port an estimate based on lines of code of port divided by the estimated average lines of code per developer per day is appealing in simplicity, but doomed to fail for all the reasons given on this page.

A more sensible approach would be: -

  1. For an on-the-spot estimate ask the developers with the most experience with the code for a gut estimate of how long it will take. This is bound to be incorrect for many reasons that I won't go into here, but it is the best that they will be able to do at the outset. At least they should have an idea whether it will be easy-peasy done in a week or years away even with additional resources. If there have been any similar sized ports or pieces of work done, they could use this as a guide.
  2. Estimate the port by component to get a total sizing. Tasks that are not directly related to the port need to be included, such as setting up infrastructure (machines, build systems, etc), investigating and purchasing software, etc.
  3. Identify the riskiest components of the port and start with those first. These are likely to blow out the estimate the most, so should be done up-front if possible so that there are limited surprises late in the port.
  4. Keep track of the progress against the sizing done in step 2 to continually calculate the expected duration of the port. As the project moves ahead this should become more accurate. Of course, the number of lines of code that have been ported (features in the original code base that are now in the ported code) can also be used as a metric and is actually helpful to ensure that the original product is being ported rather than a bunch of cool new functionality being added while not tackling the actual port.

These would be the bare-bones steps, of course there are many other activities around this that are helpful such as investigating porting tools and pluggable frameworks, creating prototypes, determining what really needs to be ported, reusing test tools and infrastructure, etc.

Not the answer you're looking for? Browse other questions tagged or ask your own question.