[andrewstuart]

10 lines per developer day - this is so outdated it should be disregarded entirely. Not much is gained from writing articles around this "10 lines a day" assertion unless you're writing something about computing history.

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.

[sampsonitify]

People misunderstand it. It means writing code, documentation, testing, bug fixing etc.

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.

[kjksf]

No, we don't misunderstand it. 10 lines per day is just rubbish.

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.

[barrkel]

Multi-team development is radically different to a two-person project, especially when it's in production with lots of money depending on it.

You can't rewrite much without the risk of breaking things, so you need a lot more testing. There's a lot of value in the code, so there's more to leverage to add functionality, but the other side is there's more to learn and analyze to efficiently leverage. And when there's lots more teams working on the code, there's more of it and it changes faster than you can expect to fully comprehend; you're continually analyzing and learning.

When I'm off on my own, spiking a new service or library, I can churn out 10k to 20k lines a month; it's very easy when it's greenfield, when there's no team coordination overhead, when you don't need to refactor other people's stuff when you redesign, you don't need to go through full code review cycle, the whole thing fits inside your skull etc. But that doesn't last forever, and it's not business as usual for feature development.

Fixing a gnarly bug might take several days of investigation and end up with a 1 line fix; and delivering that fix might make the difference in avoiding 6 or 7 figures worth of revenue churn. Does that mean it's 10000x less productive?

[pgt]

It sounds like you wrote 20-30 lines per day part-time over 10 years, which is within an order of magnitude of 10 lines per day for the average developer. Sounds about right to me?

[nudpiedo]

I also think that's correct, regarding the order of magnitude, familiarity with the topic... the 10 lines a day (order of magnitude) could perhaps make more sense from a perspective of cognitive overload.

[_pmf_]

> I didn't spend 15 years writing it. It's a part-time effort over 10 years.

It's not that far off. I'm taking your example as rather confirming the point rather than refuting it.

[JamesBarney]

2 people is a pretty small project and by the looks of it it probably didn't involved nearly as much coordination as most large business apps. I also imagine you didn't have to do much coordination with project managers, qa, business analysts, architects, other devs, etc.

When I worked on a big project (several million lines of code) I routinely would code less than 10 lines per day.

[majewsky]

> 10 lines per day is just rubbish.

For you. For the average developer, on the large scale, I think it is closer to the truth than you'd think.

[downerending]

It doesn't sound like this was done within the context of a corporation, which slows things down a lot. Also, it has 424 open issues right now--is it really bug fixed?

(Also, not a fan of back-jumping 'goto's or putting executables in git repos. And s/supressing/suppressing/g)

You seem like a fine programmer, but I don't think this invalidates MMM.

[jammygit]

Recommend me an architecture concept or book. I’m trying to learn how to keep my “velocity” up over time

Edit: you made Sumatra?? I’ve been using that for a decade, thank you so much for creating it! I put it on all my family’s machines, it’s the fastest PDF reader I’ve found

[jammygit]

Braid was 3+ years iirc (according to a gamasutra interview I read)

[andrewstuart]

>>>People misunderstand it. It means writing code, documentation, testing, bug fixing etc.

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.

[google234123]

Sorry but you won't get much done only writing 10 lines of code per day.

[pixelrevision]

10 lines written is low but context also really matters. If you are building a greenfield project then averaging 10 loc a day is not going to work out. However if you are the guy on your team who fixes all the nastiest bugs or cleans up legacy code then you will be writing a fraction of that.

[jammygit]

My last company had a code base with X LOC and Y engineers, and it took Z years to write. It was medical software, so it was very heavily tested. It worked out to about 14-20 LOC per day per engineer, although for the first few years the team was smaller so let’s say 28-40 during those years (maybe even doubled once or twice temporarily when the company was founded). The slowness later on made up for the speed early on

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

[Insanity]

I think today we still have days / weeks like this. But averaging it out over a year you'd probably get more than 10 lines of _code_ per day yeah. Not counting comments. Say I'm working on something complex - I'll be happy with 10 working lines of code per day. But if I'm making a webpage, I'd damn well hope to get more than 10 lines of HTML/CSS out. Well, HTML at least.