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.
No way, you're telling me 15 3 is the same as 3 15? :O
Mythical man month: 10 lines per developer day
31–40 of 212 posts
Re: Mythical man month: 10 lines per developer day
#3210 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…
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 term coding lines per day, versus multi-year coding.
Re: Mythical man month: 10 lines per developer day
#33Seems about right, on the average day, you put about 500 in. the average year later, you're lucky if 10 of those are left. sits back waiting to be told how badly I suck and something about code churn and patterns
Re: Mythical man month: 10 lines per developer day
#34Over 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…
"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 to reduce drag on features you'll write in the future. When you write requirements, do refactoring, test things, write documentation, etc you are being productive. Your future self will thank you for the effort you put in to the non-code work now.
Re: Mythical man month: 10 lines per developer day
#35What 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.
Expecially because the big picture is easily stated: Write the least amount of clean code while providing value.
(PS: code is liability)
Re: Mythical man month: 10 lines per developer day
#36Earlier 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
I think what had happened is somebody had designed the file and everybody else followed suit patching stuff on - the entire codebase for that app was well below average. they had front end devs who didn’t know any JavaScript. In 2016. I lasted 6 months before I nope.png’d the fuck out.
It’s still not the worst application I’ve ever worked on though
Re: Mythical man month: 10 lines per developer day
#37Re: Mythical man month: 10 lines per developer day
#38Over 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…
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…
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.
Re: Mythical man month: 10 lines per developer day
#39Earlier quoted context omitted.
I would love to hear more details on this one
It was a C# file for an API that wrapped thousands of reports with a function call for each report, I moved to a design which was a single function for all reports. I think what had happened is somebody had designed the file and everybody else followed suit patching stuff on - the entire codebase for that app was well below average. they had front end devs who didn’t know any JavaScript. In 2016. I lasted 6 months be…
Re: Mythical man month: 10 lines per developer day
#40Earlier 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.
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.