Live data from Hacker News

Mythical man month: 10 lines per developer day

blog.ndepend.com

71–80 of 212 posts

Re: Mythical man month: 10 lines per developer day

#71
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…

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.

Re: Mythical man month: 10 lines per developer day

#72
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…

Whenever I spend a week without progress I feel like dying. In college I was used to be able to churn immense amount of code. Even if most of it was useless, I'm not well adjusted for long productive-less periods. How did your manager react to these times ? no remarks ? nagging ? trusting ?

Progress is measured in more things than code written. Define progress using the right metric, i.e. stuff learned, and the feeling of progress and your motivation can be preserved.

For me, it is really a top down approach. I can work on goals that take years to accomplish. But the key is to break them down into smaller and smaller bits until you have work items that show progress on a small enough scale to be easily observable. And part of this is sometimes research, so I can't measure myself in terms of code or features. But each task usually has a way to define progress.

Re: Mythical man month: 10 lines per developer day

#73
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…

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?

Re: Mythical man month: 10 lines per developer day

#74
post #72

Earlier quoted context omitted.

Whenever I spend a week without progress I feel like dying. In college I was used to be able to churn immense amount of code. Even if most of it was useless, I'm not well adjusted for long productive-less periods. How did your manager react to these times ? no remarks ? nagging ? trusting ?

Progress is measured in more things than code written. Define progress using the right metric, i.e. stuff learned, and the feeling of progress and your motivation can be preserved. For me, it is really a top down approach. I can work on goals that take years to accomplish. But the key is to break them down into smaller and smaller bits until you have work items that show progress on a small enough scale to be easily…

Good point. I do agree with you vastly. But in my few work experience it was never discussed nor shown. Which led .. well lack of leadership. And ultimately deep anxiety.

Do most jobs have a team chat to talk about it before going into actual work ?

Re: Mythical man month: 10 lines per developer day

#75
post #35

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.

Everytime I read posts like this is like if people are arguing about the tiny details of the small picture, and it makes me sad. Expecially because the big picture is easily stated: Write the least amount of clean code while providing value. (PS: code is liability)

Code is both asset and liability; the asset is the feature set, while the liability has an interest payment in the form of maintenance.

The way you put it, you're optimizing for only one side of the books. The fact is that the value in a company is not in minimal clean code; it's in a recurring revenue stream, and ideally profits. Provide the most value with code which has low interest payments. Everything else being equal, smaller code has lower interest payments, but everything else isn't always equal. And depending on cash flow and market opportunity, maximizing value and to hell with minimal clean code - throwing money & devs at the problem - can make sense.

Re: Mythical man month: 10 lines per developer day

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

AOP tools that effectively rewrite the app have incredible amounts of leverage. That can work to your benefit but it's also an enormous footgun if you get your aim wrong. It leverages up both cleverness and stupidity.

Re: Mythical man month: 10 lines per developer day

#77
post #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 i…

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.

Re: Mythical man month: 10 lines per developer day

#78
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…

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?

Re: Mythical man month: 10 lines per developer day

#79

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.

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.

Re: Mythical man month: 10 lines per developer day

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

Less code less problems...

However in many cases, code is for; edge cases, input sanitization, type checking, null checking, graceful failure, logging... etc

Remember, [1] Docker can be implemented in a 100 LOC bash script, that doesn't mean it's a good implementation...

[1] https://news.ycombinator.com/item?id=9925896

Post reply on HN