Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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)

share|improve this question

closed as primarily opinion-based by gbjbaanb, MichaelT, GlenH7, Giorgio, Dan Pichelman Oct 12 '13 at 18:30

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

7  
Do those lines need to have any quality embedded? >_> –  dr Hannibal Lecter Jan 26 '11 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... –  GrandmasterB Jan 26 '11 at 8:46
6  
Credible source: Mythical Man Month. –  Loki Astari Jan 26 '11 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. –  Mark Freedman Jan 26 '11 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 '12 at 10:29

25 Answers 25

up vote 81 down vote accepted

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.

share|improve this answer
17  
That number might even drop so sharply as to get into the negative ... –  Hans Kesting Jan 26 '11 at 10:07
3  
@SK-Logic is it? Try translating a casual conversation, then try translating a long legal document. –  BlackICE Jun 17 '11 at 15:10
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 '12 at 9:17

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.

share|improve this answer
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 '11 at 8:08

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.

share|improve this answer
1  
MxGrath: SLOC is only bad for measuring progress, but it's often usable for measuring the overall complexity, esp. since, as Les Hatton pointed out, "McCabe Cyclomatic Complexity has the same prediction ability as lines of code." –  pillmuncher Jun 17 '11 at 16:14

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

This question can be used as a good trick to test how much attention a developer pays to the quality of the code he or she is putting up.

It is incorrect to use a precise figure on the lines of code to plan out a project. The ultimate aims and the quality should be kept in mind, before splitting the work into sub-tasks.

Coming to the OP's question, my answer would be 'no' because there's no exact figure you can quote, and 'yes' because it should trigger a discussion on the final objectives.

share|improve this answer

Ugh... this is a "company" smell!

As soon as I hear this type of thing it gives me the shivers and reminds me of using
TSP/PSP at my old company.

share|improve this answer

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.

share|improve this answer
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 '11 at 9:25

I think it should be a character count. I mean, does a 'long' time have the same value to him as a 'short' line? I can envision briljant scenarios here..

" yeah we made the target, but then I refactored the code and we're screwed. QUICKLY, UNDO!"

tl;dr; it's a ridiculous question. I would propably talk to the executive and explain to him why these figures don't mean anything. He obviously is in the dark here, so you need to help him define other measures to add to the project planning.

share|improve this answer
1  
Ok! string thisIsMyReallyLongStringVariableName = NowIWillMakeMyClassNamesReallyLong.MethodNamesToo(isntThisFun); –  Marcie Jan 26 '11 at 14:39

Sounds about correct.

http://stackoverflow.com/questions/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

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.

share|improve this answer

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...

share|improve this answer

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.

share|improve this answer
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. –  Mark Freedman Jan 26 '11 at 14:14
1  
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 '11 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 '11 at 11:03

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.

share|improve this answer
I 
can
write
large
numbers
of
lines
of
code
per
month.

Proportional to the number of words, in fact.

You see my point?

share|improve this answer
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 '11 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. –  Jon Harrop Mar 28 '12 at 9:16

This is an appropriate story:

http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt

Developer works for a week and manages to write -2000 lines of code.

share|improve this answer

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.

share|improve this answer

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

If they are good, less than zero.

share|improve this answer
4  
+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 '11 at 15:16
1  
Of course it is meaningless @mh. this is more of a tongue-in-cheek answer –  qes Nov 20 '12 at 15:15

Any day in which my net output of LOC is negative is a good day.

share|improve this answer

This is why "lines of code" as a measurement isn't really that good:

if (variable == value) { doSomething(); }

versus

if (variable == value) {
  doSomething();
}

versus

if (variable == value)

{

  doSomething();

}

All three code blocks do the same thing, but the person who wrote the third obviously has more lines of code than the other two.

share|improve this answer
1  
SLOC are standardized (that's the S), so those are nominally the same number. –  Brian Carlton Jan 28 '11 at 22:36

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!

share|improve this answer

At the start of a project, it is easy to write any number of lines of code. It is suggested that the avg is 100 lines of good code a day. However as you get furtherer into a project and start doing refactoring, it is easy to get into the negative loc of code a day.

For example. Day 1 - I write function A() that has 100loc. (+100 loc) Day 2 - I use function A() 50loc. (+ 50 loc) Day 3 - Refactor 150loc form the last two days with a 3 line linq statement. (-147 loc)

holy crap, I must be terrible, I wrote negetive lines of code!!! Oh wait, that is just why loc is a terrible metric. :)

share|improve this answer

"...For example. Day 1 - I write function A() that has 100loc. (+100 loc) Day 2 - I use function A() 50loc. (+ 50 loc) Day 3 - Refactor 150loc form the last two days with a 3 line linq statement. (-147 loc) - holy crap, I must be terrible..."

Yes you are terrible!! You should have written the 3 lines of LINQ on the first day and not wasted two days of the company's time.

I would never accept a developer on one of my teams that could only produce 10 LOC/day (fully debugged, etc.) - that's pitiful offshore speed - they better be charging me $20/hour or less for the guy

share|improve this answer
1  
LOC really is an irrelevant way to judge a programmer. –  Matthieu Dec 9 '11 at 5:31

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.

share|improve this answer

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 :)

share|improve this answer

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

The rate at which the code can be translated is dominated by the design decision of whether you do this manually or automatically. Manually means paying people to mechanically translate bits of code from one language to another. Automatically means paying someone to write a compiler that does it for you. A compiler could eat a million lines of code every second. If you are porting a large code base (over a million lines of code), I recommend going for the automated solution.

share|improve this answer

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.

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

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).

share|improve this answer

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.

share|improve this answer

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