Live data from Hacker News

Mythical man month: 10 lines per developer day

blog.ndepend.com

21–30 of 212 posts

Re: Mythical man month: 10 lines per developer day

#21
post #5

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…

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.

[deleted]

Re: Mythical man month: 10 lines per developer day

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

Re: Mythical man month: 10 lines per developer day

#23
post #5

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…

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

The only place I've ever been at that had any sort of lines of code measurement also tracked lines removed, This was on a points system and in fact removal of code was considered worth more points as long as it didn't break build (there was also some other stuff about if it was rolled back or the lines you had written were changed in a short time that points were removed) There was also some points for removing TODOs etc.

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.

Re: Mythical man month: 10 lines per developer day

#24
post #15

Earlier quoted context omitted.

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.

I would love to hear more details on this one

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.

Re: Mythical man month: 10 lines per developer day

#25

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.

Agreed. Worse, I have yet to see someone that gave better estimates than someone that could give a rough "good faith" loc estimate.

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?

Re: Mythical man month: 10 lines per developer day

#27
post #15

Earlier quoted context omitted.

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.

I would love to hear more details on this one

Not OP but also replaced a class. Very early in my career, I think I was 20, we were upgrading our Thrift version in a PHP/Java stack.

For some reason all calls were dog slow. Like minutes for simple pages.

Profiling revealed the class in question - and we were spending all our time in deserializing strings.

Copied the latest version of that class from the FB repo and luckily the interfaces were the same.

Worked for the next two years until we finally deprecated the PHP stuff.

Re: Mythical man month: 10 lines per developer day

#28

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…

It looks like the author is showcasing his product, hence the random screenshot of test coverage as well.

Re: Mythical man month: 10 lines per developer day

#29

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.

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.

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

Re: Mythical man month: 10 lines per developer day

#30

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.

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

The greatest, most joyous programming is deleting large chunks of code.
Post reply on HN