
Mythical man month: 10 lines per developer day - rcsorensen
https://blog.ndepend.com/mythical-man-month-10-lines-per-developer-day/
======
antirez
I did some trivial math. Redis is composed of 100k lines of code, I wrote at
least 70k of that in 10 years. I never work more than 5 days per week and I
take 1 month of vacations every year, so assuming I work 22 days every month
for 11 months:

    
    
        70000/(22*11*10) = ~29 LOC / day
    

Which is not too far from 10. There are days where I write 300-500 LOC, but I
guess that _a lot_ of work went into rewriting stuff and fixing bugs, so I
rewrote the same lines again and again over the course of years, but yet I
think that this should be taken into account, so the Mythical Man Month book
is indeed quite accurate.

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.

~~~
fiblye
Has progress on that been fairly continuous with the project growing steadily
(almost) nonstop? Or was a big portion of that the groundwork just to get it
to a point of being usable in the beginning?

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.

~~~
antirez
I think this went quite constant. The main change is that in the first years I
could work a ton of stuff 1 month, zero the next month, and now is instead
more smoothed evenly.

------
bArray
What annoys me most about these metrics is that some days zero lines are
written. Anything up to a month without results to show.

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.

~~~
Bnshsysjab
At one job, I replaced a 10k LOC class with a 20 line function which probably
took me to a net negative loc count for that job.

~~~
tomcam
I would love to hear more details on this one

~~~
erikerikson
Not the GP but... Reduce a cross cutting concern from a system into an aspect
and you get this easily.

I once worked on a product and identified an ability to eliminate 100K lines
of poorly written, inconsistent tracing code into a robust ~250 line file
using AspectJ. Management threw a sh-t fit and thought the risk was untenable.

~~~
croon
The risk of the new one or the risk of keeping the old 100K lines? Half
serious question since I would estimate the risk of the latter to be much
larger.

~~~
gmueckl
To me it sounds like he was introducing a hard dependency on AspectJ, which is
as much a risk as any other dependency. I am guessing here, bit it is a
scenario where a hissy fit from management has at least some justification.

~~~
scarface74
How is a dependency on AspectJ any more of a liability than the dozens of
other external dependencies in your typical application?

~~~
gmueckl
It is just as much of a liability, a priori neither more nor less. It needs to
be evaluated like any other potential new dependency.

Plus, AspectJ is something that you have to be careful with. It injects code
at the start or end of methods that can do arbitraty things and the method
source code doesn't indicate that this is happening. So it has a great
potential for code obfuscation.

~~~
scarface74
Sort of unrelated rant. Maybe it’s because I’m not as well versed in Java
idioms as I am with C# idioms, but using code that implements AOP using
AspectJ seems much more obtuse than what I’ve done in C# just looking at the
examples.

In C#, with the various frameworks - including on the API level with ASP.Net -
you can use attributes to decorate the classes/methods with your aspects and
it’s pretty easy to see what it’s doing.

You get the runtime binding basically by just using dependency injection as
you always do.

~~~
logicalmind
C# dev here as well, but from a Java background. When I first moved to C# from
Java one of the best AOP usages was transaction management. Database
transaction management. You could write all of the code, whether it was
dependent upon the db or not, and then decorate the methods with a transaction
attribute. This decoration contained all the logic to get a db connection,
begin a transaction, become part of an existing one, or create a new isolated
one. Any unhandled exception caused the final unwinding to rollback any work
that had been done in that transaction. So many try/catch/finally's avoided
and so much boilerplate code.

I have yet to find any equivalent to this .NET world. Especially of you're
using EF. Either you use ADO and have your try/catch/finally with manual
transaction management, or you have the EF context which is just one big blob
you hope succeeds at the end.

~~~
scarface74
TransactionScope has been around forever in the .Net Franework version of EF.

It just came back to EF Core in 2.1

[https://www.google.com/amp/s/codewala.net/2018/05/06/transac...](https://www.google.com/amp/s/codewala.net/2018/05/06/transactionscope-
a-simple-way-to-handle-transactions-in-net/amp/)

~~~
logicalmind
Yes, this is exactly the type of boilerplate I am talking about. All those
usings and try/catch blocks which add needless code. It is possible to compose
all of this into an aspect which then decorates your methods. Maybe I'm not
being clear, so here is what I mean. Say you have a method that does some
work, but calls some other thing to do some auditing. The auditing is nice,
but it failing shouldn't halt the world.

    
    
      [Transaction]
      DoYourBusinessWork() { ...; AlsoAudit(); }
    
      [Transaction(RequiresNew, NoRollbackFor(AuditException)]
      AlsoAudit() { ... }
    

The TransactionScope is handled in the aspect. Commit/Rollback is all handled
there is well. There are not usings or exception handlings within your methods
unless you want to handle those specifically.

~~~
scarface74
There should only be one using/try catch block on the highest level. All of
the methods being called within that using block should just throw errors.

You could put the logic in attributes but I don’t consider a transaction a
cross cutting concern. It would create a spooky action at a distance
situation.

~~~
logicalmind
It's obviously highly dependent on the domain in which you work, but I would
consider what you're saying to be a "business transaction" more than a
"database transaction". If there is a 1:1 between the two then your way works.
I tend to have situations where one business transaction is multiple database
transactions. And the business transaction can succeed even if some of the
underlying database transactions were to fail.

------
seventh-chord
Not quite sure what point the author is trying to make? He agrees that lines
of code are a bad measure of productivity because, yet claims that the average
he computes can help him predict future development times. Then he explicitly
points out that different parts of the codebase required different amounts of
work, apparently unrelated to their code line count, yet does not relate this
to the previously mentioned points. Also, what is up with the random comment
about code coverage at the end? That doesnt fit in with the rest of the
article either...

~~~
nitwit005
Even the assertion of that knowing the lines of code per day helps with
estimation seems puzzling. How do you know how many lines the finished product
will eventually have in advance?

~~~
techbio
How do you know how many pixels the ball will take up in a sports photograph
before capturing it?

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.

------
dmos62
My current task is to implement a feature and I wrote about 50 lines during
the last 2-3 weeks. I'm not slacking off, just examining the codebase and
planning. I did collect about ~25-50 lines of notes per day though, so it's
not like I'm keeping everything in my head. To be fair, the codebase is new to
me, so I don't expect to keep this tempo for very long.

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.

~~~
cwingrav
I once opened up a government code base (in C) that lead with this: "void * *
* * x;". It took a while to learn that code. Taking time is fine and good
managers will support you, so long as you have something to explain what your
time is spent on.

~~~
m0zg
I'm consulting a client right now and their C++ codebase is full of gems of
this caliber. I eviscerate every single PR, and tell them what's wrong and
why, and then their CTO just merges them into master without changing
anything. All the while they pay me for it. Why? Fuck me if I know. They hired
me to provide advice. I provide advice, and it's pretty expensive. I _know for
a fact_ they will regret merging this shit. I can explain why, in a way a
toddler would understand. And yet they still do it. Smh.

~~~
dmos62
You might be going into conflict/criticism mode, which would make them
unresponsive. Being right isn't enough to get people to change. I don't know
at all if this is the case, just mentioning it, because you seem to be
frustrated by the situation.

~~~
m0zg
I actually asked them if this want me doing this. They said they did. This is
only a minor part of what I'm doing for them - my work is mostly on the AI
side.

------
Tade0
_a professional developer will write on average 10 lines of code (LoC) day._

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.

~~~
Insanity
That's a pretty big range - but I'd say frontend code tends to be faster /
take up more lines. Center a button, give it a colour, make it responsive and
you've probably reached your 30 lines of HTML/CSS :P

~~~
nudpiedo
but the fine tuning, bugs and corrections, reported issues and other aspects
should be part of the metric too. The days were there i barely progress
because some alignment is not working and coordination with the design team is
taking the time makes it part of the average as well

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

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

------
z3t4
Anyone else feel sad when you remove a bunch of code? All those man-hours it
took to write that code, and now I'm deleting it all. I believe it's called
sunk cost fallacy. I often wish I had a time machine so that I could go back
in time and say, hey, this will all be deleted a year from now, go with the
other solution instead.

~~~
Jtsummers
Nope. One of my first experiences with removing many lines of code was in
college. It was a compilers project (we had to hand-write it, no YACC or
anything). I had written about 10k lines of code in a flurry of activity, and
discovered some really gnarly bugs.

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.

------
cpascal
My company has been experimenting with doing our feature estimations in LOC
changed instead of points (1, 2, 3, 5). The general idea being that point
estimation can vary between engineers based on ability, but LOC changed should
be similar among engineers. This is supposed to make it easier to answer
management's favorite question of "How long is this gonna take?". The answer
is calculated using a team's historical average LOC/hr rate.

It remains to be seen if our estimates are any better.

~~~
Cpoll
I wonder if LOC changed isn't often reversely proportional to time taken.

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.

~~~
cpascal
I think for defect estimation you are right, but for feature estimation (new
code, not fixing bad code) the correlation is positive.

------
jammygit
Over the last 2 months I’ve managed about 3k new loc and 90 classes, so that’s
about 60ish lines per work day. I don’t feel like I was that productive though
and spent a lot of time refactoring. Eg, last 1k lines barely added any
features

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)

~~~
onion2k
_I don’t feel like I was that productive though and spent a lot of time
refactoring. Eg, last 1k lines barely added any features_

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

~~~
mytailorisrich
This is the engineering point of view, but in a business productivity is
judged from a business point of view.

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.

~~~
onion2k
_When you refactor code you do not deliver value to customers.._

You do though, by reducing the future cost of delivering features. That has
tremendous value. Find a company that sees good engineering as a long term
investment rather than a short term way of extracting money from customers and
you'll enjoy software development _a lot_ more.

~~~
weego
Again that isn't customer facing value. Users do not care about the costs of
your business, I cannot understand how so many developers don't seem to
understand the basic premise of b2c relationships. At best it's the
proposition of future benefits and those benefits are all to the company not
the customer.

~~~
viklove
> Again that isn't customer facing value.

It absolutely is customer facing value. If shipping this feature 2 weeks later
means you can ship the next 10 features in 6 months, and the alternative is
shipping this feature today but with so much tech debt that you ship the next
10 features in 12 months, then that is value the customer will see.

Similarly, if your code is so shitty that you're adding bugs to the backlog
faster than you're able to fix them, that's a negative for the customer. If
instead you spend 2 weeks refactoring so that your bugs+ rate is lower than
your bugs- rate, that's customer value right there!

I cannot understand how you don't seem to understand this basic premise of a
b2c relationship. Users don't just care about the features they have today,
and if your competitor gets to market slower than you but has twice the
features a year or two later (due to less tech debt), you're gonna be left in
the dust.

------
jillesvangurp
That book was written in the seventies, 45 years ago. It still has valid
points but obviously a few things have changed in terms of how we do things.
For example, we use version control systems these days and have sophisticated
refactoring tooling.

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.

~~~
andrewstuart
>> we haven't really come up with any better metrics than time spent and nr.
of things changed per time unit

Does anyone give a shit about metrics any more? I seem to recall the whole
metrics thing fizzled out entirely about 15 years ago.

~~~
tfigment
OKRs are a thing in tech circles. John Doerr wrote a book on it. My company
rolled it out and most people struggle with coming up with meaningful metrics
for their job.

~~~
karatestomp
We added OKR junk at an agency I worked at. For developers our options were:

1) use silly, useless metrics that are of a sort management will accept
anyway,

2) uselessly tag along with initiatives in areas that are easier to measure
(sales, marketing kind of though their metrics are still usually bad, just no-
one cares),

3) start a year ago gathering data for a baseline for bad development metrics,

4) start 2-3 years ago gathering data for good development metrics, though
they’ll probably still be pretty limited and narrow.

We picked 1 and 2 of course. What a waste of time. I wish anyone who wanted to
be more than a line worker anywhere had to answer some basic questions about
games and measuring things. Not just in development, managers and directors
everywhere are, on average, terrible at it as far as I can tell.

------
zackmorris
We should probably be using the absolute value of lines of code, so abs(LOC)
as the metric, or something like a least squares mean for estimating the
moving average of LOC per day.

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.

------
throwaway100x
My project at work is 60k LOC, developed over the course of 3 years. It's in
production and works quite well. I wrote it all by myself. My hobby project is
100k LOC (2.5 years of development in free time). Both are UI + service code
in C++. I code several hours a day. Maybe 3-5 on average.

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.

------
scarejunba
Guys, can I be honest? I have never actually met anyone who has worked in a
LOC-optimized company. This stuff seems like the outrage porn of software
engineering.

~~~
heisenbit
You misunderstand the intention. You don't optimize LOC but you develop
software as best as you can. You measure - among other things - LOC and this
gives you at least some hard figures in the fuzzy software engineering
universe. See it as the Hubble constant - it gives you answers about the
universe provided you know it's value.

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!

~~~
scarejunba
I'm talking about all of these comments on this page with people talking about
how LOC/day is not a good metric for productivity. So? No one's tying your
wages to LOC/day.

------
hermitcrab
I did some analysis of my own projects and came up with around 50 LOC per day:
[https://successfulsoftware.net/2017/02/10/how-much-code-
can-...](https://successfulsoftware.net/2017/02/10/how-much-code-can-a-coder-
code/)

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?

------
tom_hill
Another post currently on the front page has a great example of this:
[https://news.ycombinator.com/item?id=22306002](https://news.ycombinator.com/item?id=22306002)

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!

------
m0zg
I wish I had a job where writing 10LOCs per day would be enough. I wrote
quarter of a million LOCs at Google alone, and I wasn't the most prolific
programmer on the team, not even close. I wrote about as much code since I
left Google, too. And it's not Java code either, where your IDE has to crap
out 100 lines of boilerplate before you even begin to do anything meaningful.
This is mostly C++ and in the last few years Python as well.

~~~
pso
How long were you at google for, and how long since you left? Otherwise, the
numbers don't offer much insight.

------
speleding
I'm a 10x programmer, so I do 100 lines per day ;-)

------
paulajohnson
The 10 LOC/day includes the entire project, including analysis, requirements,
design, documentation (user and tech), test, management etc, in a large
project. Saying (as many do) that an individual programmer has produced
hundreds of LOC per day is to miss the point.

You have to start by defining your terms of reference and make sure you are
comparing like with like.

------
ChrisCinelli
If you are doing a good refactoring, you may have a massive negative LoC at
the end.

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.

~~~
WalterBright
Anytime I see a good chunk of redundant/useless code removed, it's a good day!

~~~
andrewstuart
The greatest, most joyous programming is deleting large chunks of code.

------
thrower123
I'm not sure I add 10 lines of code, on average, to our products a day. Most
days are probably negative, to be honest.

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

------
mettamage
How I explain why LoC is a bad metric to non-techsavvy people.

3 +

3 +

3 +

3 +

3 +

3 +

3 +

3 +

3 +

3 +

3 +

3 +

3 +

3 +

3 = 45

And so is 3 * 15.

~~~
VectorLock
I once had to work with some outsourced developers who would do "something();
something(); something();..." rather than "for(int i = 0; i < 10; i++)
something();" when instructed to repeat something X times.

~~~
ascar
It's called loop unrolling and improves performance by eliminating loop
control overhead and reducing branch mispredictions. Maybe they had a compiler
background :)? /s

~~~
ktpsns
If they had, they would know that virtually any compiler can do this on his
own.

I also know these examples and I know the people who are writing them. "Copy &
Paste" coding is just more convenient for them instead of writing a loop,
fizzling with brackets, indation or whatever. They don't produce high entropy
code.

------
magicalhippo
I've never found LOC as a useful metric for productivity. Lines of code are
most definitely not born equal.

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?

------
eeZah7Ux
A good bricklayers places MORE bricks in a day than others.

A good construction engineer builds a house using LESS concrete that others.

I'd rather be a good software engineer than a "x10 developer".

------
ww520
A good measure is how many lines removed per day.

~~~
woutr_be
That’s a terrible metric in my opinion. Yes, removing redundant code or
optimising code is important, but I wouldn’t want to be judged on it.

------
toadi
This is still a thing... working in the field for 20 years and really is 15
years ago LOC as KPI went away... Why is it back?

------
talkingtab
Does anyone else question the mythical man month? If I accept the basic
assumption of the mythical man month then I also have to accept that NYC is a
myth - there is no way that a city that size can possibly function. Lets start
out with ten people in NYC and they add ten more people .... My own belief is
the MMM is an apologists view of how we currently collaborate to develop
software and products.

~~~
Jtsummers
What do you question about it? The point of the specific essay was that the
work of development/engineering cannot be sped up linearly by adding people.
You still see this attitude with managers today: The team of 5 is running
behind, let's put that other team on the same project, now it's 10 people. But
those 5 new people:

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.

------
Koshkin
Well, this depends on the language. I once wrote 12,000 lines of x86 assembly
code in four (long) days.

------
collyw
Personally I take more pride in removing code these days.

------
B008L355
Mumps developers only need to write 1 line of code a day

------
dusted
Seems about right, on the average day, you put about 500 in. the average year
later, you're lucky if 10 of those are left.

 _sits back waiting to be told how badly I suck and something about code churn
and patterns_

~~~
edflsafoiewq
Empirical proof you wrote refactorable code :)

~~~
dusted
ya, and that they keep changing the requirements.. :)

------
rdiddly
Anybody know how he made those treemaps?

~~~
supermatt
ndepend :)

[https://www.ndepend.com/docs/treemap-visualization-of-
code-m...](https://www.ndepend.com/docs/treemap-visualization-of-code-metrics)

~~~
rdiddly
a-DOIIIII!! of course

------
nodomain
Shouldn't that article be removed from HN? For me it looks like click bait to
promote his nDepend tool.

------
fctorial
3, take it or leave it.

------
not_buying_it
lol I average about 200 a day, guess I'm not a pro:(

------
shultays
sounds like I am at least a 10x programmer

------
Brave-Steak
Am I mad? Did anybody actually read the article? Why is everybody piling on
LoC/day when the article is about average LoC over a period of time and how it
correlates to the work you're doing and what a realistic average LoC might
look like for a sane project. From this point of view, it doesn't matter at
all if you deleted 20k lines and have a negative LoC for the day. That's
missing the forest for the trees.

~~~
laichzeit0
C’mon man you should know better than that by now. Here on HN you only read
the headline. Nobody actually reads the article. At most you read a few
comments to get the gist of what people think the article might be about.

------
iamaelephant
This is just an ad for NDepend.

------
grumple
Web devs: don't think this applies to you.

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.

~~~
timwaagh
This is why people push the most difficult tasks to the most junior
developers. Because a dev stuggling to do the 'impossible' looks the exact
same way. That way others get to protect themselves from blame.

~~~
grumple
> This is why people push the most difficult tasks to the most junior
> developers.

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.

