70000/(22*11*10) = ~29 LOC / day
However this math is a bit off because in the course of such 10 years I wrote quite a number of side projects, but still, max ~50 LOC / day.
I don't have hard figures to easily consult but I'd guess that I'm at about your average in total, but then on the days when I'm refactoring/debugging existing stuff, honestly it could be like 3 lines a day, or 5, or just planning/sketching something out.
It's like the old mechanic trope. It's not hard to replace a bolt, what's hard is knowing which bolt to replace and where.
On my most productive (in my own estimation) brownfield days in recent memory, the codebase would generally shrink by several hundred LOC.
I also find that a huge factor in my code production rate on brownfield projects might not have much to do with me, because it's factors like, "Is the code well-documented, easy to understand, and backed by tests that make the intended behavior clear? Or do I have to start by burning days or weeks on wrangling with Chesterton's Fence?"
And, on the other side of it, when is documenting and cleaning my own code to guard some future maintainer from that situation vital, and when am I burning a day of my own time to save someone else only an hour in expectation? All I know for sure in that situation is that, if my manager is assiduously counting LOC, ticket close rate, anything like that, then game theory demands that I should never bother to spend an extra hour on making it more maintainable if I expect that the cost of that decision will be born by one of my teammates. The 10X rockstar developer at a previous team of mine taught me that lesson in a rather brutal manner.
With projects I work on, I'll often write a few thousands lines of foundation in a couple weeks, then I'm adding a line here and there as needed. The first 1000 lines are always easy. The next 10 can take days.
If I'm pounding out the same boilerplate code I've written for every greenfield app, I can go at a phenomenal speed. But if I'm put into code I'm not very familiar with, 98% of my effort is understanding the existing code and 2% of it is making that 1-10 LOC change.
I remember when I was prototyping an OpenGL thing on SunOS or a Renderman on same (maybe Solaris?), I was working ALL of the time and cranking out LOTS of code. Then refactor-refactor, fix technical debt, slowly add features without breaking, more automated tests, more platforms, and then, tada! My effective rate of coding (measured by LoC) was depressingly low.
I guess that I'm happy that it appears that I'm effective and relatively efficient, but I'm not the LoC-cranking-out machine that I thought I was. Sobering.
Where, then, does all this time go? Sometimes it's reading existing code. Sometimes it's learning about a new algorithm by reading blogs and papers. Sometimes it's developing test programs to iron out a bug or test out some new code.
There used to be one chap in the office that got all the hard problems - the seriously hard problems. Some of this was figuring out why USB couldn't transition from low-speed mode to high-speed mode reliably (USB is quite hard to probe due to frequency), or figuring out why the application crashed one in a million boots.
Some of our most valuable developers committed the least amount of code, but saved our arses more times than I can count.
Many software roles require what I would call Home Depot skill levels. People at Home Depot take semi-finished materials in a kit and fix their toilet, without understanding how it works.
Likewise, some journeyman skilled developer and “code” a sign in page with an API without understanding the engineering process around OAuth.
The problem is many business people don’t understand anything beyond the Home Depot kit... they see stuff on the shelf and don’t understand that at some level that engineering side of the work needs to be done to create something novel. Reinforcing that notion are vendors hawking products.
That said, I probably don't want to be building a house from scratch with my level of skills and should hire someone with specialized knowledge. Likewise it's also an important skill to know when you will be in over your head and when you need to hire someone to get a job done correctly
I think those of us in roles like this can actually bang out a lot more LOC than somebody working on lower level problems, because we aren't solving hard problems, we're using basic data structures and tossing them between (usually/hopefully) well documented interfaces. If that's the case, LOC is just about the worst metric you could imagine.
Expecially because the big picture is easily stated: Write the least amount of clean code while providing value.
(PS: code is liability)
However in many cases, code is for; edge cases, input sanitization, type checking, null checking, graceful failure, logging... etc
Remember, [1] Docker can be implemented in a 100 LOC bash script, that doesn't mean it's a good implementation...
After I left, I heard the company 10x programmer replaced it with 10KLOC of C++. (sigh)
I once had a senior manager who insisted that developers made at least one commit a day (an internal GitHub like tool gamified this: number of lines committed since last month / top committers in the team etc), and those that didn't, had to up their game.
It was frustrating to say the least as this was not the only metric. There were a handful and, frankly, many made a mockery of it by doing just as much or less work than before but achieving or even surpassing the said metrics.
It worked pretty good because there was only a team of 4-5 people on any product at any time so someone just removing TODOs and not fixing the issues pointed out by the TODOs would have been caught.
I used to work for a company that bills their customers for dev hours spent. The software they put together worked fabulously well - in the production of billable dev hours.
In college I was used to be able to churn immense amount of code. Even if most of it was useless, I'm not well adjusted for long productive-less periods.
How did your manager react to these times ? no remarks ? nagging ? trusting ?
It's also a hell of a lot of fun... which is why it's not really what you get paid for. What you get paid for is the long, tedious slog of the real world: maintaining existing business logic, teasing out user requirements in a domain you don't really understand, dealing with other developers who have different preferences and skill levels, doing variations of the same thing instead of exploring new domains and technologies. You spend a lot of days in meetings that should have been emails.
It's not all drudgery, and it's both more fun and better paid than 99% of the jobs in the world, but it's not picking the wondrous low-hanging fruit that you did in college.
For me, it is really a top down approach. I can work on goals that take years to accomplish. But the key is to break them down into smaller and smaller bits until you have work items that show progress on a small enough scale to be easily observable. And part of this is sometimes research, so I can't measure myself in terms of code or features. But each task usually has a way to define progress.
It is of course the main metric for global warming, but it can be used badly or very well. Just like Lines of Code, it's hard to even get the measurement right. Do you measure it in the sun, or the shade? Do you measure it in a city which is relevant to the where most people feel the effects, or in the country so you get a repeatable environment. Similarly does LOC include comments and blank lines, what about patches - how do you count them? In terms of LOC per day, so you measure a single person who is churning out the code, or the entire team including the designers and documenters, and do you include the time after the project is completed doing support because of bugs?
I don't think you can blame the "temperature metric" for the bad ways it's measured or used. And I don't think you can blame Lines Of Code all of it's bad outcomes either.
Like measuring productivity by how many hours people spend at their desks. Utterly pointless, but really easy so it becomes the default measure.
Trying to explain to professional managers that there is no foolproof way of measuring developer productivity is a really hard conversation that I've had more than once. I'm assuming the OP's target market is exactly these people, so I don't really blame them for succumbing to the pressure.
Enough to see it, not so many that you can’t see everything else.
Same with lines of code, except that instead of a photographer, there is an observing project manager.
If I had been pressured to start writing code immediately it would have been more difficult to comprehend the codebase, thus slower, or even worse I would have introduced anti-features or bugs.
My experience so far is a team of developers can deliver 30-100 LoC per day of front-end code.
The team size is of little consequence. It's been hilariously consistent across projects and companies I've been in.
Maybe this was true when people were writing operating systems in assembly language - which is the time and context in which The Mythical Man Month was written.
Lines of code per day really is a pretty meaningless measure but having said that there is at least some truth to it, in that any developer who is writing a typical 21st century application and getting only 10 lines of code per day written, should really examine if they are in the right job.
I'm not sure it is that far off over several years. If you look at Google, and say there are 52 * 5 days * 10 lines of code, 2600 lines of code per developer. Extrapolate that to 20 years times how many developers and list on code that is currently used, would it be that far out?
People over-estimate the sustainability of short term coding lines per day, versus multi-year coding.
Here's an example: https://github.com/sumatrapdfreader/sumatrapdf is code written by 2 people (me and another guy).
It's written, documented, tested and bug fixed.
It's 110k lines of code. And it's tight. Good luck removing 10k lines of code and not loosing any functionality.
Assuming 10 lines per day and round-the-clock 365 days of working, that's 30 man-years of work. 15 years for 2 people.
I didn't spend 15 years writing it. It's a part-time effort over 10 years.
The 10 lines per day is off by at least an order of magnitued.
And I don't claim to be spectacularly productive. Jonathan Blow wrote 90k lines of code for Braid in 1 or 2 years.
Are you sure about that?
I don't think so.
I have not read it for years, but my vague recollection of The Mythical Man Month is that 10 lines a day as a full time professional programmer is a reasonable expectation if you are writing IBM mainframe operating systems in assembly language in the 1970s.
It not meant to be saying that hey a programmer is busy with lots of other things like testing documentation etc.
Brooks actually meant it, and it was true, at the time, with 1970s hardware, with 1970s development tools, with 1970s collaboration, 1970s compilers/assemblers, 1970s source control, with 1970s level of understanding of computers and software, with 1970s waterfall style project management. And, critically, writing your 10 lines as part of a (relatively speaking) gigantic project for the time. Back then projects did not come much bigger than writing an operating system.
Can you imagine trying to get your bit written of some gigantic project where probably no-one has any idea what the fuck is going on, where the source code is, what version is what, who is working on what and how its all meant to tie together. The miracle is that they could get any operating system at all written. Many, many operating system projects failed entirely in the 1970's and 1980's.
I'm happy to be proven wrong, cause as I say I haven't read that book for a long long time.
In terms of lines of changes total in git merges, multiply it by 10 or more.
edit: updated loc numbers to include some file types that I forgot about
I spent a day with just a pencil and paper, considering each detail of the algorithms and came up with several key insights which reduced the whole thing to about 1k lines of code. The reduction was a combination of C macros (which I wouldn't use today, but I'd use higher-order functions to accomplish the same thing now) and just smart generic code (no special handling of an add operator versus a multiplication operator, they were both binary operators; differentiating the output for each case happened in one place at the end).
That was when I found out I liked deleting code. I'll happily reduce a code base by 90% if the result is clearer and easier to maintain or extend.
And then 'getting rid of code' is the most wonderful feeling in the world.
Getting rid of unneeded code is like clipping toe-nails that are way too long. (It must be done!)
It's like cleaning a disgusting floor in the bathroom (it can't wait).
It's like fixing ugly grammar and spelling mistakes.
It's like sanding and painting that old fence the really needed some attention.
If its taking 100 lines to do something and I can rewrite in 10, then that's a lot less places for bugs to hide. That's less than one screen of code for the next person to read / comprehend. In most cases its a win (though I will admit that sometimes comprehension is easier with less concise code).
At some point, I close the patient, discarding a lot of that. At the end of the day, ideally it looks pretty minimal--just what's needed and no more.
It remains to be seen if our estimates are any better.
500 LOC feature: Add a new route that does something boring; 5 story points.
5 LOC feature: Fix mysterious performance degradation in X; 13 story points.
What do you do to keep up a fast pace in a big project without throwing quality out? They say TDD increases your speed overall, according to a few case studies I found (15% longer to code, but 40% less bugs, so faster finish times overall etc)
"being productive === adding features" is a very negative way to think about development, and exactly the sort of mindset that leads to projects that grind to a halt under the weight of tech debt. Good software comes from all the parts of the process, including maintenance of the code base to reduce drag on features you'll write in the future. When you write requirements, do refactoring, test things, write documentation, etc you are being productive. Your future self will thank you for the effort you put in to the non-code work now.
The goal of software development is to deliver chargeable value to customers.
When you refactor code you do not deliver value to customers and since you have spent time and resources to do that your overall productivity from a business point of view has in fact dropped.
There are multiple Dilbert strips on this topic.
But one of the things that hasn't changed is that we haven't really come up with any better metrics than time spent and nr. of things changed per time unit. There are a lot of people complaining these things are not representative (for the last five decades) but not a whole lot of people coming up with better productivity metrics and even fewer that did the leg work of actually validating their work in something that might pass scientific scrutiny (which is hard). If you do work in this space, you'll find yourself citing articles that are decades old.
These days, I tend to look at the activity statistics on github projects when joining a new project. It tells me in a glance of an eye who are the movers and shakers on a project in terms of lines of code added/removed and amount of commits and the time distribution of those commits. It's not perfect and doesn't tell you the complete story but it it's rarely completely wrong. Usually it's quite easy to spot patterns like Weekends, Christmas, vacations, and that people tend to get back energized from a good break (a little spike in productivity).
Also these numbers confirm the notion of a 10x programmer: a handful of people tends to be responsible for the vast majority of commits and line changes. Not all software engineers are created equally. Diffstats on pull requests tell me a lot as well; though of course these numbers are inflated by e.g. refactorings (more so on languages that have proper tools for this). But refactoring is a good thing and combined with code reviews tell you a lot about the quality of engineering.
Does anyone give a shit about metrics any more? I seem to recall the whole metrics thing fizzled out entirely about 15 years ago.
What's that law? Something like "Once a number becomes a goal, it ceases to be a useful measure."
Anymore, my daily average LOC is probably negative since I tend to rescue floundering projects. I usually avoid object-oriented (OO) programming whenever possible, as I've found that functional one-shot code taking inputs and returning outputs, with no side effects, using mostly higher order functions, is 1 to 2 orders of magnitude smaller/simpler than OO code.
Also I have a theory that OO itself is what limits most programs to around 1 million lines of code. It's because the human mind can't simulate the state of classes with mutable variables beyond that size. Shoot, I have trouble simulating even a handful of classes now, even with full tracing and a debugger.
I'd like to see us move past LOC to something like a complexity measurement of the intermediate code or tree form.
And on that note, my gut feeling is that none of this even matters. The world's moving towards results-oriented programming, where all that matters is maximizing user satisfaction over cost of development. So acceptance test-driven development (ATDD) should probably be highest priority, then behavior-driven tests (BDD), then unit tests (TDD). On that note, these take at least as long to write as the code itself. I'd even argue that they express the true abstractions of a program, while the code itself is just implementation details. Maybe we should be using user stories implemented per day as the metric.
10 LOC/day is ridiculous. Think about Brad Fitzpatrick, Fabrice Bellard, John Carmack. They would never accomplish anything like they did with those 10 LOC.
You have to have dedication and really good text editing skills. Being smart is nothing if you can't write code fast enough. Good skills with tools like shell, debugger, version control are important as well.
Another problem is that dev collectives these days tend to bully and punish those with higher performance. There are several reasons for that 1) most devs do an absolute minimum just not to get fired 2) job security is a thing, you won't make your project look too simple or complete as this might end your contract 3) at least 90% of hype is from idiots and by idiots. Idiots are a heavy tax on any engineering 4) frameworks, tools and methodologies are often designed for a different scale 5) ceremonia, overcomplication of development processes, treating devs like anonymous, interchangeable units
I'm male in my 40s with a CS degree. I work from home most of the time.
That is, honestly list out roughly what all code the naive way will touch or generate. Without making assumptions about cheating the metric. If you can bring yourself to that, you can probably give better estimates than you'd expect.
Instead, we seem to constantly look for ways to cheat the metric. With no real reason to do so. Other than push the cheating/gaming into a harder sector?
Then when it comes to understanding your software costs - it helps you to put some numbers to features. Yes it is dark art but so is all other financial magic. When it comes to maintenance or re-engineering software - LOCs and past numbers can be useful but are not the only determinant of future development costs. There is the agile backlog / planning poker school of thought which is certainly an improvement and valuable running the project but when it comes to large scale software projects it is not an answer I would like to rely on when the project needs a price tag before day one.
It is one metric. If you work in any company purely run on metrics - if you ask me - run once you see a better place. If you work in any company not measuring what it does - run now!
Not only that, but the higher-level concept I took away is that, given the size of his features (~6k loc), it takes about 75 days to write a feature. Assuming those are workdays, that's 15 weeks, a little over a quarter. And, indeed, tech companies do seem to measure their process and projections in quarters, and everything tends to slip to the right a bit, on average.
Also, the code coverage numbers line up with other estimates I've seen: life-critical systems should have upwards of 95% code coverage. Standard project: 85-90% coverage.
But: -As a 1-man-band I also do the support, documentation, testing, website, marketing etc. So coding is only part of what I do. -I don't think the article defines what a LOC is. Does it include headers? Does it include auto generated code?
How do you score this for lines of code per day. ?
> I've added 700k lines of code and deleted 747k (yay negative!).
Interesting that if you divide the added lines by the 7 years, and figure 250 days/year, he's phenomenally productive
700,00 / 7 / 250 = 400 lines of code per day, sustained over 7 year!
You have to start by defining your terms of reference and make sure you are comparing like with like.
LoC added or removed is not a very good metric for anything.
Except if I see a big negative number on a PR, it is usually a great thing. I still have to check what was removed but it usually mean that things are easier to understand.
Of course, any time I have to add a new Windows Forms dialog to our install/config utility, there's a couple thousand lines of code-behind added to the repo...
3 +
3 +
3 +
3 +
3 +
3 +
3 +
3 +
3 +
3 +
3 +
3 +
3 +
3 +
3 = 45
And so is 3 * 15.
So what's this obsession about it? Is it managers who can't or don't want to properly evaluate the performance of the people they're managing?
A good construction engineer builds a house using LESS concrete that others.
I'd rather be a good software engineer than a "x10 developer".
1. Don't know the code base or problem domain. So they'll spend months getting up to speed.
2. Will increase the communication overhead (now each person has to coordinate with up to 9 others, not just 4).
On the small scale of this example, you may see good results. 5 more people isn't a huge amount of communication overhead, and if they're experienced (perhaps even formerly worked on the same or similar project) then you'll see an immediate drop in productivity and then a quick rise back to the new baseline. But will that hold with another 10 people? 20 more beyond that? Each doubling will not continue to halve the time to develop the project, there are limits, and at some point the returns will be negative. The additional people will slow it down. Not just the initial slow-down, but also the new baseline after things settle will be lower than before adding them.
sits back waiting to be told how badly I suck and something about code churn and patterns
If you're pushing up 0 lines of code on a day where you had no meetings or interruptions, and you aren't working on something truly novel and near-impossible, you took the day off on the company dime. And everybody you worked with noticed, and if you do it regularly - they are just waiting for everybody to reach their breaking point with you so they can push to get rid of you. Sure, you'll find a new job and do it again, but you'll still not have anybody's respect.
Who does that?
The correct thing is to manage expectations and then do the work. Unfortunately there are many lazy developers (or people in any sort of job) who won't be productive with even the most simple tasks.