Live data from Hacker News

Mythical man month: 10 lines per developer day

blog.ndepend.com

111–120 of 212 posts

Re: Mythical man month: 10 lines per developer day

#111

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.

Large organizations function very poorly in a lot of respects. They're also the only way to get a lot of things done. In a lot of ways, it is often a bit surprising to me that large companies can coordinate activities to come out with useful outputs. On the other hand, there are clearly inefficiencies that don't exist with a 10-person startup.

Re: Mythical man month: 10 lines per developer day

#112

Earlier quoted context omitted.

Some of my favourite days on the job is when you remove lines of code. Does that metric go against LOC/written?

Reminds me of https://www.folklore.org/StoryView.py?story=Negative_2000_Li... 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 ha…

I know I'm against popular opinion to the extreme here, but I'm not altogether against that (the commit every day bit, not the LOC competition bit).

Few reasons:

1. I find devs (including me) tend to do too few commits instead of too many. Smaller, tighter commits are better, but it's really tempting to try and do an entire feature in one commit.

2. If someone has spent a couple of days working on something without committing it, I'd be concerned that they're stuck, or spinning wheels. I'd check in on them. Not in a bad "you're not working hard enough" way, but in a "do you need help?" way.

3. If someone often spent more than a day without writing anything they could commit, I'd check in on them. Again, like 2. above, not in a "dammit work harder!" way, but maybe it's an indication that they're getting handed the really hard problems, or that they need some more training, or that they're going through some personal stuff, or something.

but measuring lines in each commit is pointless/futile, as is measuring number of commits in a day.

Re: Mythical man month: 10 lines per developer day

#113
post #70

Earlier quoted context omitted.

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.

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

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.

Re: Mythical man month: 10 lines per developer day

#114

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 po…

I think they're stuck with the same problem as every dev manager. LoC are pointless/futile/etc, but they're really easy to measure and they're got to measure something right?

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.

Re: Mythical man month: 10 lines per developer day

#115

Earlier quoted context omitted.

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

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.

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.

Re: Mythical man month: 10 lines per developer day

#116

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 pret…

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.

Re: Mythical man month: 10 lines per developer day

#117
post #52

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.

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

Re: Mythical man month: 10 lines per developer day

#118
post #87

Earlier quoted context omitted.

Reminds me of https://www.folklore.org/StoryView.py?story=Negative_2000_Li... 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 ha…

What was the turnover rate at that place? This would have me quit within a week.

When the stocks weren't rallying as they are now, the attrition was higher by industry standards. Either way, they do have forced attrition, too [0].

[0] https://news.ycombinator.com/item?id=22295120

Re: Mythical man month: 10 lines per developer day

#119

Earlier quoted context omitted.

Reminds me of https://www.folklore.org/StoryView.py?story=Negative_2000_Li... 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 ha…

I know I'm against popular opinion to the extreme here, but I'm not altogether against that (the commit every day bit, not the LOC competition bit). Few reasons: 1. I find devs (including me) tend to do too few commits instead of too many. Smaller, tighter commits are better, but it's really tempting to try and do an entire feature in one commit. 2. If someone has spent a couple of days working on something without c…

I can sort of see the rationale for this, but it's been a long time since I've worked anywhere where this was feasible even 50% of the time; nobody wants fragments of a feature in trunk, and the codebases tend to be inflexible. "Commit to branch", sure; branches are cheap.

> If someone has spent a couple of days working on something without committing it, I'd be concerned that they're stuck, or spinning wheels. I'd check in on them.

This is more reasonable. Working without review leads to worse fiascoes the longer it goes.

Re: Mythical man month: 10 lines per developer day

#120
post #37

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.

Not at all.

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

Post reply on HN