Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mythical man month: 10 lines per developer day

blog.ndepend.com

Post reply on HN
Print view View original

161–170 of 212 posts

Re: Mythical man month: 10 lines per developer day

#161

Post by milesvp »

virgilp wrote: post #126
thomk wrote: post #124

Earlier quoted context omitted.

Interesting so maybe the more accurate way to measure is increase LOC + decrease LOC.

Or even better, don't measure LOC.

LOC is a terrible measure for productivity, but I like to think about it more as a measure of capacity. LOC/day is useful as an upper bound in the same way pages per day is an upper bound for authors. Stephen King is notorious for being one of the most prolific writers, and he can’t produce more than 8 publishable pages a day (top hit on google suggests his average may be close to 6). Knowing that the number of LOC/day is so low on average, can really help keep estimates honest, and remind us how truly difficult what we do actually is.

Re: Mythical man month: 10 lines per developer day

#162

Post by mumblemumble »

hinkley wrote: post #151
mumblemumble wrote: post #123

Earlier quoted context omitted.

This "LOC as a proxy for productivity" metric seems so much harder to measure in a useful way on brownfield work. On my most productive (in my own estimation) brownfield days in recent memory, the codebase would generally shrink by several hundred LOC. I also find that a huge factor in my code production rate on brownfield projects might not have much to do with me, because it's factors like, "Is the code well-docume…

> I should never bother to spend an extra hour on making it more maintainable if I expect that the cost of that decision will be born by one of my teammates. If you want to be a team lead, though, or even just have people follow your lead, I find that not only do you want to worry about these costs, but you need to talk openly about them, and be seen addressing it. Most devs follow the ones they trust, no matter what…

> If you want to be a team lead, though... you want to worry about these costs...

This may depend on the extent to which your organization conforms to the Peter principle.

Re: Mythical man month: 10 lines per developer day

#163

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

Re: Mythical man month: 10 lines per developer day

#164

Post by logicalmind »

scarface74 wrote: post #132
gmueckl wrote: post #113

Earlier quoted context omitted.

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.

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…

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.

Re: Mythical man month: 10 lines per developer day

#165

Post by JeremyNT »

Spooky23 wrote: post #106
bArray wrote: 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…

That’s fundamentally a lack of respect for the engineering aspect of software systems and a sort of self-loathing embraced by people in the field. Many software roles require what I would call Home Depot skill levels. People at Home Depot take semi-finished materials in a kit and fix their toilet, without understanding how it works. Likewise, some journeyman skilled developer and “code” a sign in page with an API wit…

I'm another mostly "Home Depot" coder and can glue all kinds of things together without really having to dig deeper. Maybe I could go deeper if I needed to, but that's not what my job demands or requests of me, and what they need is the Home Depot code that bolts all their existing systems together.

I think those of us in roles like this can actually bang out a lot more LOC than somebody working on lower level problems, because we aren't solving hard problems, we're using basic data structures and tossing them between (usually/hopefully) well documented interfaces. If that's the case, LOC is just about the worst metric you could imagine.

Re: Mythical man month: 10 lines per developer day

#166

Post by jammygit »

mytailorisrich wrote: post #38
onion2k wrote: post #34

Earlier quoted context omitted.

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

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.

My hope is that the refactoring today will pay me back over the next 6 months in saved time / stability

Re: Mythical man month: 10 lines per developer day

#167

Post by downerending »

Bnshsysjab wrote: post #7
bArray wrote: 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.

At one job, I wrote a moderately complicated Makefile (~200 lines) to build the company's product. Worked great.

After I left, I heard the company 10x programmer replaced it with 10KLOC of C++. (sigh)

Re: Mythical man month: 10 lines per developer day

#168

Post by iamatworknow »

z3t4 wrote: 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 don't get sad when that code is deleted. I get sad when the people deleting it bash it as being "bad code", especially when they are new hires who don't know any of the context behind why that code is the way it is. Nobody wants to write "bad code", but every code base has some. Thankfully, with time and experience, developers usually mature from "who wrote this trash?" to "this code served its purpose, but we can make it better".

Re: Mythical man month: 10 lines per developer day

#169

Post by jammygit »

kjksf wrote: post #49
sampsonitify wrote: post #32

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…

Braid was 3+ years iirc (according to a gamasutra interview I read)

Re: Mythical man month: 10 lines per developer day

#170

Post by downerending »

kjksf wrote: post #49
sampsonitify wrote: post #32

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 doesn't sound like this was done within the context of a corporation, which slows things down a lot. Also, it has 424 open issues right now--is it really bug fixed?

(Also, not a fan of back-jumping 'goto's or putting executables in git repos. And s/supressing/suppressing/g)

You seem like a fine programmer, but I don't think this invalidates MMM.

Post reply on HN