Live data from Hacker News

Mythical man month: 10 lines per developer day

blog.ndepend.com

51–60 of 212 posts

Re: Mythical man month: 10 lines per developer day

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

I experience the opposite reaction. I'm elated! Especially when a conditional can be removed/refactored. That's 1/2 as many tests. 1/2 as many possibilities for something to go wrong. As long as the functionality remains the same (or simpler) I love to delete code. Especially my own.

Re: Mythical man month: 10 lines per developer day

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

Re: Mythical man month: 10 lines per developer day

#53

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

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

Re: Mythical man month: 10 lines per developer day

#54

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…

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?

Re: Mythical man month: 10 lines per developer day

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

Re: Mythical man month: 10 lines per developer day

#56
post #15

Earlier quoted context omitted.

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.

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.

Re: Mythical man month: 10 lines per developer day

#57

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…

At my last Java job, whenever there was a day I didn't have much or any code to commit (e.g. I was in the middle of going through compsci papers about a nontrivial algorithm I intended to implement), I would open up the IntelliJ's "code inspections" tab. It provided me with a never-ending stream of quick and small fixes to make that not only amounted to a commit, but also occasionally fixed an actual (if not likely) bug.

Re: Mythical man month: 10 lines per developer day

#59
post #49

Earlier quoted context omitted.

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

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

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

Re: Mythical man month: 10 lines per developer day

#60
post #40

Earlier quoted context omitted.

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.

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.

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.
Post reply on HN