Live data from Hacker News

Mythical man month: 10 lines per developer day

blog.ndepend.com

171–180 of 212 posts

Re: Mythical man month: 10 lines per developer day

#171

Earlier quoted context omitted.

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

TransactionScope has been around forever in the .Net Franework version of EF.

It just came back to EF Core in 2.1

https://www.google.com/amp/s/codewala.net/2018/05/06/transac...

Re: Mythical man month: 10 lines per developer day

#172

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…

My last company had a code base with X LOC and Y engineers, and it took Z years to write. It was medical software, so it was very heavily tested. It worked out to about 14-20 LOC per day per engineer, although for the first few years the team was smaller so let’s say 28-40 during those years (maybe even doubled once or twice temporarily when the company was founded). The slowness later on made up for the speed early on

In terms of lines of changes total in git merges, multiply it by 10 or more.

edit: updated loc numbers to include some file types that I forgot about

Re: Mythical man month: 10 lines per developer day

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

Nope. I liken it to exploratory surgery. Towards the beginning, I'm pulling everything apart, writing scaffolding to try things out, discovering along the way what's needed and what's not.

At some point, I close the patient, discarding a lot of that. At the end of the day, ideally it looks pretty minimal--just what's needed and no more.

Re: Mythical man month: 10 lines per developer day

#174

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.

There are people that care, but metrics are as useless as ever for measuring programmer quality.

What's that law? Something like "Once a number becomes a goal, it ceases to be a useful measure."

Re: Mythical man month: 10 lines per developer day

#175
post #4

Over the last 2 months I’ve managed about 3k new loc and 90 classes, so that’s about 60ish lines per work day. 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 What do you do to keep up a fast pace in a big project without throwing quality out? They say TDD increases your speed overall, according to a few case studies I found (15% longer t…

In a lot of places, quality is not a priority. Or even, it can be an anti-priority: First you get rewarded for producing prodigious amounts of crap code, then you get rewarded again for the heroic efforts it takes to fix that crap code.

There are multiple Dilbert strips on this topic.

Re: Mythical man month: 10 lines per developer day

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

Recommend me an architecture concept or book. I’m trying to learn how to keep my “velocity” up over time

Edit: you made Sumatra?? I’ve been using that for a decade, thank you so much for creating it! I put it on all my family’s machines, it’s the fastest PDF reader I’ve found

Re: Mythical man month: 10 lines per developer day

#179
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 think this an interesting analogy. Taking it further - what's great about the Home Depot level skills is that they are often sufficient for me to be able to do routine basic maintenance. This is in-part because many things have become simpler and designed to be easily/cheaply replaced. I think the same could be said for software. That's generally a good thing and was an intentional movement in the industry

That said, I probably don't want to be building a house from scratch with my level of skills and should hire someone with specialized knowledge. Likewise it's also an important skill to know when you will be in over your head and when you need to hire someone to get a job done correctly

Re: Mythical man month: 10 lines per developer day

#180

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 ?

College coding is very misleading. It's usually clean-sheet, by yourself, with idealized requirements and few dependencies. It's rarely robust or tested extensively, and its lifespan is short. It's also a hell of a lot of fun... which is why it's not really what you get paid for. What you get paid for is the long, tedious slog of the real world: maintaining existing business logic, teasing out user requirements in a…

This is also why I prefer to use projects inspired by real projects at work to test out new programming languages or technology. It's really easy to make something look good by just ignoring the messy realities of the real world. It's a lot harder if you're doing an experimental rewrite of a system with real world requirements attached to it.
Post reply on HN