Software lines per day

Bear that in mind next time you estimate how long something is going to take. If you have data on LOC per day for sizeable projects worked on over an extended period, please post it in the comments.

It will only take you a few minutes to get the stats using Source Monitor which is free. Interesting post, Andy.

IIRC ,one or more of them were referring to lines of debugged, tested code, with that metric. I know you are too, about your own, But yes, I agree it does seem low, intuitively [1], and also that it is likely close to realistic. But when you consider it as working code, things start to look different. One thing, though, there will be a lot of variation, depending on the complexity of what you are writing. In fact, after a while, I developed a sort of system for it sort of sorting and classifying them by similarity and difference, and reusing as much code as possible, so it was like I only had to write the delta between the previous report and the next , and found that it then went a good amount faster, and still with correct code :.

One metric to measure productivity which I use in my company is to look at tasks and see how many of them were completed by the programmer on time based on the estimates provided earlier.

As a solo developer, your LoC per day per person will probably be higher than a large team of developers, because you spend less time figuring out how someone else wrote some part of the code base. At least that is my experience with larger teams. So it seems my numbers are not an outlier.

So how much code do programmers average per day? I have a strong feeling to kneel and worship So you guys do a minimum of LOC per workday?

Honestly that sounds high, especially when you take design, testing, and integration into account. I can't imagine hitting lines per day. The question is meaningless. I write hundreds of lines of code a day, but the majority of it is either writing generic CRUD with the occasional tricky data manipulation, or rewriting dodgy old ASP code into dodgy new.

NET code. My brother writes code to handle the vehicle AI in simulation software. I'm sure I write 10 times the amount of code he does, but I'm also sure I'm not working 10 times as hard more likely the other way around. The of lines is otally irrelevant and fairly uninteresting. I didn't start this thread to reignite the tools discussion. I was more interested in hearing how many lines of code the pro devs in the symposium kick out per day. So in my environment - lines per day is about right.

Some days it could be , others zero, other when refactoring is considered. I feel like I wrote about 10 lines of code today! So painful. It can be tough going when you inherit code with no documentation, no unit tests etc. At least by tomorrow I'll be able to give my boss the answer to one of the questions he's been looking for though. I guess at the end of the day all that matters is what you achieve not how many lines of code you write. I can only dream or have nightmares!!

I've spent many days writing a few lines of code to fix something in the thousand lines that someone else did in a day.

LOC is meaningless. I'm writing some cool lisp code these days. I can knock out lines per day of shit like foo. But it is a lot of code. However, the interesting shit say, fusing data from numerous sensors and manual inputs into an authoritative report winds up being a fewer lines of code, but takes far longer to figure out.

You spend three days staring off into space or scribbling on a whiteboard before writing the first line of code. Then you have to take the language into account.

A Quicksort in C takes ish lines of code; in Haskell it takes 5. So when you say, "an average developer can do lines of code per day," my question is, doing what? In what language? For what purpose? I really doubt it - we can code a lot because there are only 3 of us, and we have low coupling between ownership areas. That doesn't scale well to large, highly interconnected systems. Now I'm debugging other people's work, so I may write zero lines in a day, just fixing a few of theirs.

Nonetheless, LOC isn't the most useful number, as many have pointed out. If working an actual work week, I suspect your rate is going to drop quite a bit. Oh certainly. I wonder what that POS stands for. Do you realise that a team of 10 developers working for one year at that speed would only produce lines of code? Does that seem reasonable to you? I was thinking of a way to say something similar Last Thursday, for example, one of the things I did was write a new function for our codebase in about an hour after studying the problem and figuring out what it needed to do including justifying it by testing of the existing code and showing why we needed a new function and presenting my arguments to our team leader I actually added about as much commentary as I did code for this one.

I then spent a couple hours testing all the permutations of that code so that was about 10? That's not too bad, IMO. I've gone through design phases that took months and testing that took months as well as documentation comments in code as well as any other like a wiki or something, etc. You have to add all that in as well.

This reminds me of the story: Lines of Code from folklore. Depending on the project and the development environment, yes. I'll say it again; you cannot meaningfully compare LOC counts as a measure of productivity without providing context. I've certainly had spurts where I've rattled off double that in a week's time, but I'm most proud of all the code that I haven't written. Today I learned that my e-peen is very small. I just wrote a quick script to count non-whitespace LOC and it looks like I've written about 20, lines of Python code in the last months.

Yeah, I don't envy anyone working on a 1 million-LOC codebase. That's not true at all. For example, when i inherit a codebase, i generally follow the '3 strikes and you're out' rule. All tasks were tracked in JIRA. The second project was an open source Java product, developed by an extremely distributed team of about 15 developers. We discussed everything in GitHub issues. Both projects hosted their code bases on GitHub.

Both teams were developing in feature branches - even for small fixes. Both teams used build automation, continuous integration , pre-flight builds, static analysis and code reviews. This indicates the maturity of the project teams.

Both projects satisfied the requirements of their users. There was no garbage and almost no code duplication. In both projects, my role was called that of lead architect, and I knew their financial details. Besides that, I had access to both Git repositories, so I can measure how many new lines or changed lines were introduced by both teams in, say, a three-month period.