16 ms·

Mythical man month: 10 lines per developer day

280 points by rcsorensen 7y ago

seventh-chord 7y ago
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 points. Also, what is up with the random comment about code coverage at the end? That doesnt fit in with the rest of the article either...
- ChrisCinelli 7y ago
  I am glad I am not the only one to scratch my head...
- blauditore 7y ago
  It looks like the author is showcasing his product, hence the random screenshot of test coverage as well.
- nitwit005 7y ago
  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?
  - techbio 7y ago
    How do you know how many pixels the ball will take up in a sports photograph before capturing it? Enough to see it, not so many that you can’t see everything else. Same with lines of code, except that instead of a photographer, there is an observing project manager.
- marcus_holmes 7y ago
  I think they're stuck with the same problem as every dev manager. LoC are pointless/futile/etc, but they're really easy to measure and they're got to measure something right? Like measuring productivity by how many hours people spend at their desks. Utterly pointless, but really easy so it becomes the default measure. Trying to explain to professional managers that there is no foolproof way of measuring developer productivity is a really hard conversation that I've had more than once. I'm assuming the OP's target market is exactly these people, so I don't really blame them for succumbing to the pressure.
dusted 7y ago
Seems 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
- edflsafoiewq 7y ago
  Empirical proof you wrote refactorable code :)
  - dusted 7y ago
    ya, and that they keep changing the requirements.. :)
jammygit 7y ago
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 to code, but 40% less bugs, so faster finish times overall etc)
- onion2k 7y ago
  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 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.
  - mytailorisrich 7y ago
    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.
    - onion2k 7y ago
      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.
bArray 7y ago
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 hard problems - the seriously hard problems. Some of this was figuring out why USB couldn't transition from low-speed mode to high-speed mode reliably (USB is quite hard to probe due to frequency), or figuring out why the application crashed one in a million boots. Some of our most valuable developers committed the least amount of code, but saved our arses more times than I can count.
- Bnshsysjab 7y ago
  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.
  - tomcam 7y ago
    I would love to hear more details on this one
    - erikerikson 7y ago
      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.
      - croon 7y ago
        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.
ww520 7y ago
A good measure is how many lines removed per day.
- woutr_be 7y ago
  That’s a terrible metric in my opinion. Yes, removing redundant code or optimising code is important, but I wouldn’t want to be judged on it.
fctorial 7y ago
3, take it or leave it.
ChrisCinelli 7y ago
If you are doing a good refactoring, you may have a massive negative LoC at the end. LoC added or removed is not a very good metric for anything. Except if I see a big negative number on a PR, it is usually a great thing. I still have to check what was removed but it usually mean that things are easier to understand.
- WalterBright 7y ago
  Anytime I see a good chunk of redundant/useless code removed, it's a good day!
  - andrewstuart 7y ago
    The greatest, most joyous programming is deleting large chunks of code.
rdiddly 7y ago
Anybody know how he made those treemaps?
- supermatt 7y ago
  ndepend :) https://www.ndepend.com/docs/treemap-visualization-of-code-metrics https://www.ndepend.com/docs/treemap-visualization-of-code-m...
  - rdiddly 7y ago
    a-DOIIIII!! of course
scarejunba 7y ago
Guys, can I be honest? I have never actually met anyone who has worked in a LOC-optimized company. This stuff seems like the outrage porn of software engineering.
- taeric 7y ago
  Agreed. Worse, I have yet to see someone that gave better estimates than someone that could give a rough "good faith" loc estimate. That is, honestly list out roughly what all code the naive way will touch or generate. Without making assumptions about cheating the metric. If you can bring yourself to that, you can probably give better estimates than you'd expect. Instead, we seem to constantly look for ways to cheat the metric. With no real reason to do so. Other than push the cheating/gaming into a harder sector?
- heisenbit 7y ago
  You misunderstand the intention. You don't optimize LOC but you develop software as best as you can. You measure - among other things - LOC and this gives you at least some hard figures in the fuzzy software engineering universe. See it as the Hubble constant - it gives you answers about the universe provided you know it's value. Then when it comes to understanding your software costs - it helps you to put some numbers to features. Yes it is dark art but so is all other financial magic. When it comes to maintenance or re-engineering software - LOCs and past numbers can be useful but are not the only determinant of future development costs. There is the agile backlog / planning poker school of thought which is certainly an improvement and valuable running the project but when it comes to large scale software projects it is not an answer I would like to rely on when the project needs a price tag before day one. It is one metric. If you work in any company purely run on metrics - if you ask me - run once you see a better place. If you work in any company not measuring what it does - run now!
  - scarejunba 7y ago
    I'm talking about all of these comments on this page with people talking about how LOC/day is not a good metric for productivity. So? No one's tying your wages to LOC/day.
mettamage 7y ago
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.
- VectorLock 7y ago
  I once had to work with some outsourced developers who would do "something(); something(); something();..." rather than "for(int i = 0; i < 10; i++) something();" when instructed to repeat something X times.
  - ascar 7y ago
    It's called loop unrolling and improves performance by eliminating loop control overhead and reducing branch mispredictions. Maybe they had a compiler background :)? /s
    - ktpsns 7y ago
      If they had, they would know that virtually any compiler can do this on his own. I also know these examples and I know the people who are writing them. "Copy & Paste" coding is just more convenient for them instead of writing a loop, fizzling with brackets, indation or whatever. They don't produce high entropy code.
- jeen02 7y ago
  No way, you're telling me 153 is the same as 315? :O
  - mettamage 7y ago
    Yep, it's commutative.
- downerending 7y ago
  You joke, but I've seen code almost exactly like this in commercial software.
andrewstuart 7y ago
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 pretty meaningless measure but having said that there is at least some truth to it, in that any developer who is writing a typical 21st century application and getting only 10 lines of code per day written, should really examine if they are in the right job.
- sampsonitify 7y ago
  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 term coding lines per day, versus multi-year coding.
  - google234123 7y ago
    Sorry but you won't get much done only writing 10 lines of code per day.
  - andrewstuart 7y ago
    >>>People misunderstand it. It means writing code, documentation, testing, bug fixing etc. Are you sure about that? I don't think so. I have not read it for years, but my vague recollection of The Mythical Man Month is that 10 lines a day as a full time professional programmer is a reasonable expectation if you are writing IBM mainframe operating systems in assembly language in the 1970s. It not meant to be saying that hey a programmer is busy with lots of other things like testing documentation etc. Brooks actually meant it, and it was true, at the time, with 1970s hardware, with 1970s development tools, with 1970s collaboration, 1970s compilers/assemblers, 1970s source control, with 1970s level of understanding of computers and software, with 1970s waterfall style project management. And, critically, writing your 10 lines as part of a (relatively speaking) gigantic project for the time. Back then projects did not come much bigger than writing an operating system. Can you imagine trying to get your bit written of some gigantic project where probably no-one has any idea what the fuck is going on, where the source code is, what version is what, who is working on what and how its all meant to tie together. The miracle is that they could get any operating system at all written. Many, many operating system projects failed entirely in the 1970's and 1980's. I'm happy to be proven wrong, cause as I say I haven't read that book for a long long time.
z3t4 7y ago
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.
- jspash 7y ago
  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.
- Sharlin 7y ago
  If the code solved the original problem, as understood at the time it was written, then it was not written in vain even if changing requirements or improved understanding eventually make it redundant.
- collyw 7y ago
  Not at all. If its taking 100 lines to do something and I can rewrite in 10, then that's a lot less places for bugs to hide. That's less than one screen of code for the next person to read / comprehend. In most cases its a win (though I will admit that sometimes comprehension is easier with less concise code).
- jariel 7y ago
  Accept that it's inherently an iterative process, then you don't think 'sunk cost'. And then 'getting rid of code' is the most wonderful feeling in the world. Getting rid of unneeded code is like clipping toe-nails that are way too long. (It must be done!) It's like cleaning a disgusting floor in the bathroom (it can't wait). It's like fixing ugly grammar and spelling mistakes. It's like sanding and painting that old fence the really needed some attention.
- Jtsummers 7y ago
  Nope. One of my first experiences with removing many lines of code was in college. It was a compilers project (we had to hand-write it, no YACC or anything). I had written about 10k lines of code in a flurry of activity, and discovered some really gnarly bugs. I spent a day with just a pencil and paper, considering each detail of the algorithms and came up with several key insights which reduced the whole thing to about 1k lines of code. The reduction was a combination of C macros (which I wouldn't use today, but I'd use higher-order functions to accomplish the same thing now) and just smart generic code (no special handling of an add operator versus a multiplication operator, they were both binary operators; differentiating the output for each case happened in one place at the end). That was when I found out I liked deleting code. I'll happily reduce a code base by 90% if the result is clearer and easier to maintain or extend.
Brave-Steak 7y ago
Am I mad? Did anybody actually read the article? Why is everybody piling on LoC/day when the article is about average LoC over a period of time and how it correlates to the work you're doing and what a realistic average LoC might look like for a sane project. From this point of view, it doesn't matter at all if you deleted 20k lines and have a negative LoC for the day. That's missing the forest for the trees.
- deleted 7y ago
  [deleted]
- laichzeit0 7y ago
  C’mon man you should know better than that by now. Here on HN you only read the headline. Nobody actually reads the article. At most you read a few comments to get the gist of what people think the article might be about.
jillesvangurp 7y ago
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 lot of people complaining these things are not representative (for the last five decades) but not a whole lot of people coming up with better productivity metrics and even fewer that did the leg work of actually validating their work in something that might pass scientific scrutiny (which is hard). If you do work in this space, you'll find yourself citing articles that are decades old. These days, I tend to look at the activity statistics on github projects when joining a new project. It tells me in a glance of an eye who are the movers and shakers on a project in terms of lines of code added/removed and amount of commits and the time distribution of those commits. It's not perfect and doesn't tell you the complete story but it it's rarely completely wrong. Usually it's quite easy to spot patterns like Weekends, Christmas, vacations, and that people tend to get back energized from a good break (a little spike in productivity). Also these numbers confirm the notion of a 10x programmer: a handful of people tends to be responsible for the vast majority of commits and line changes. Not all software engineers are created equally. Diffstats on pull requests tell me a lot as well; though of course these numbers are inflated by e.g. refactorings (more so on languages that have proper tools for this). But refactoring is a good thing and combined with code reviews tell you a lot about the quality of engineering.
- andrewstuart 7y ago
  >> 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.
  - tfigment 7y 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.
Tade0 7y ago
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.
- Insanity 7y ago
  That's a pretty big range - but I'd say frontend code tends to be faster / take up more lines. Center a button, give it a colour, make it responsive and you've probably reached your 30 lines of HTML/CSS :P
  - nudpiedo 7y ago
    but the fine tuning, bugs and corrections, reported issues and other aspects should be part of the metric too. The days were there i barely progress because some alignment is not working and coordination with the design team is taking the time makes it part of the average as well
dmos62 7y ago
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.
- cwingrav 7y ago
  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.
  - m0zg 7y ago
    I'm consulting a client right now and their C++ codebase is full of gems of this caliber. I eviscerate every single PR, and tell them what's wrong and why, and then their CTO just merges them into master without changing anything. All the while they pay me for it. Why? Fuck me if I know. They hired me to provide advice. I provide advice, and it's pretty expensive. I _know for a fact_ they will regret merging this shit. I can explain why, in a way a toddler would understand. And yet they still do it. Smh.
    - dmos62 7y ago
      You might be going into conflict/criticism mode, which would make them unresponsive. Being right isn't enough to get people to change. I don't know at all if this is the case, just mentioning it, because you seem to be frustrated by the situation.
      - m0zg 7y ago
        I actually asked them if this want me doing this. They said they did. This is only a minor part of what I'm doing for them - my work is mostly on the AI side.
nodomain 7y ago
Shouldn't that article be removed from HN? For me it looks like click bait to promote his nDepend tool.
speleding 7y ago
I'm a 10x programmer, so I do 100 lines per day ;-)
m0zg 7y ago
I wish I had a job where writing 10LOCs per day would be enough. I wrote quarter of a million LOCs at Google alone, and I wasn't the most prolific programmer on the team, not even close. I wrote about as much code since I left Google, too. And it's not Java code either, where your IDE has to crap out 100 lines of boilerplate before you even begin to do anything meaningful. This is mostly C++ and in the last few years Python as well.
- pso 7y ago
  How long were you at google for, and how long since you left? Otherwise, the numbers don't offer much insight.
magicalhippo 7y ago
I've never found LOC as a useful metric for productivity. Lines of code are most definitely not born equal. So what's this obsession about it? Is it managers who can't or don't want to properly evaluate the performance of the people they're managing?
talkingtab 7y ago
Does anyone else question the mythical man month? If I accept the basic assumption of the mythical man month then I also have to accept that NYC is a myth - there is no way that a city that size can possibly function. Lets start out with ten people in NYC and they add ten more people .... My own belief is the MMM is an apologists view of how we currently collaborate to develop software and products.
- ghaff 7y ago
  Large organizations function very poorly in a lot of respects. They're also the only way to get a lot of things done. In a lot of ways, it is often a bit surprising to me that large companies can coordinate activities to come out with useful outputs. On the other hand, there are clearly inefficiencies that don't exist with a 10-person startup.
- jpalomaki 7y ago
  For me the main point in MMM was that big things take time and putting more people to work on the project does not always speed it up. The communication overhead grows exponentially as amount of people increases while the productivity only grows linearly.
- Jtsummers 7y ago
  What do you question about it? The point of the specific essay was that the work of development/engineering cannot be sped up linearly by adding people. You still see this attitude with managers today: The team of 5 is running behind, let's put that other team on the same project, now it's 10 people. But those 5 new people: 1. Don't know the code base or problem domain. So they'll spend months getting up to speed. 2. Will increase the communication overhead (now each person has to coordinate with up to 9 others, not just 4). On the small scale of this example, you may see good results. 5 more people isn't a huge amount of communication overhead, and if they're experienced (perhaps even formerly worked on the same or similar project) then you'll see an immediate drop in productivity and then a quick rise back to the new baseline. But will that hold with another 10 people? 20 more beyond that? Each doubling will not continue to halve the time to develop the project, there are limits, and at some point the returns will be negative. The additional people will slow it down. Not just the initial slow-down, but also the new baseline after things settle will be lower than before adding them.
grumple 7y ago
Web devs: don't think this applies to you. If you're pushing up 0 lines of code on a day where you had no meetings or interruptions, and you aren't working on something truly novel and near-impossible, you took the day off on the company dime. And everybody you worked with noticed, and if you do it regularly - they are just waiting for everybody to reach their breaking point with you so they can push to get rid of you. Sure, you'll find a new job and do it again, but you'll still not have anybody's respect.
- timwaagh 7y ago
  This is why people push the most difficult tasks to the most junior developers. Because a dev stuggling to do the 'impossible' looks the exact same way. That way others get to protect themselves from blame.
  - grumple 7y ago
    > This is why people push the most difficult tasks to the most junior developers. Who does that? The correct thing is to manage expectations and then do the work. Unfortunately there are many lazy developers (or people in any sort of job) who won't be productive with even the most simple tasks.
- qntty 7y ago
  thx mom
shultays 7y ago
sounds like I am at least a 10x programmer
collyw 7y ago
Personally I take more pride in removing code these days.
antirez 7y ago
I did some trivial math. Redis is composed of 100k lines of code, I wrote at least 70k of that in 10 years. I never work more than 5 days per week and I take 1 month of vacations every year, so assuming I work 22 days every month for 11 months: 70000/(22*11*10) = ~29 LOC / day Which is not too far from 10. There are days where I write 300-500 LOC, but I guess that a lot of work went into rewriting stuff and fixing bugs, so I rewrote the same lines again and again over the course of years, but yet I think that this should be taken into account, so the Mythical Man Month book is indeed quite accurate. However this math is a bit off because in the course of such 10 years I wrote quite a number of side projects, but still, max ~50 LOC / day.
- esotericn 7y ago
  From the sounds of it that also includes a decent amount of greenfield work. I don't have hard figures to easily consult but I'd guess that I'm at about your average in total, but then on the days when I'm refactoring/debugging existing stuff, honestly it could be like 3 lines a day, or 5, or just planning/sketching something out. It's like the old mechanic trope. It's not hard to replace a bolt, what's hard is knowing which bolt to replace and where.
  - mumblemumble 7y ago
    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-documented, easy to understand, and backed by tests that make the intended behavior clear? Or do I have to start by burning days or weeks on wrangling with Chesterton's Fence?" And, on the other side of it, when is documenting and cleaning my own code to guard some future maintainer from that situation vital, and when am I burning a day of my own time to save someone else only an hour in expectation? All I know for sure in that situation is that, if my manager is assiduously counting LOC, ticket close rate, anything like that, then game theory demands that 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. The 10X rockstar developer at a previous team of mine taught me that lesson in a rather brutal manner.
not_buying_it 7y ago
lol I average about 200 a day, guess I'm not a pro:(
thrower123 7y ago
I'm not sure I add 10 lines of code, on average, to our products a day. Most days are probably negative, to be honest. Of course, any time I have to add a new Windows Forms dialog to our install/config utility, there's a couple thousand lines of code-behind added to the repo...
hermitcrab 7y ago
I did some analysis of my own projects and came up with around 50 LOC per day: https://successfulsoftware.net/2017/02/10/how-much-code-can-a-coder-code/ https://successfulsoftware.net/2017/02/10/how-much-code-can-... But: -As a 1-man-band I also do the support, documentation, testing, website, marketing etc. So coding is only part of what I do. -I don't think the article defines what a LOC is. Does it include headers? Does it include auto generated code?
eeZah7Ux 7y ago
A good bricklayers places MORE bricks in a day than others. A good construction engineer builds a house using LESS concrete that others. I'd rather be a good software engineer than a "x10 developer".
toadi 7y ago
This is still a thing... working in the field for 20 years and really is 15 years ago LOC as KPI went away... Why is it back?
iamaelephant 7y ago
This is just an ad for NDepend.
cpascal 7y ago
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.
- Cpoll 7y ago
  I wonder if LOC changed isn't often reversely proportional to time taken. 500 LOC feature: Add a new route that does something boring; 5 story points. 5 LOC feature: Fix mysterious performance degradation in X; 13 story points.
  - cpascal 7y ago
    I think for defect estimation you are right, but for feature estimation (new code, not fixing bad code) the correlation is positive.
Koshkin 7y ago
Well, this depends on the language. I once wrote 12,000 lines of x86 assembly code in four (long) days.
zackmorris 7y ago
We should probably be using the absolute value of lines of code, so abs(LOC) as the metric, or something like a least squares mean for estimating the moving average of LOC per day. Anymore, my daily average LOC is probably negative since I tend to rescue floundering projects. I usually avoid object-oriented (OO) programming whenever possible, as I've found that functional one-shot code taking inputs and returning outputs, with no side effects, using mostly higher order functions, is 1 to 2 orders of magnitude smaller/simpler than OO code. Also I have a theory that OO itself is what limits most programs to around 1 million lines of code. It's because the human mind can't simulate the state of classes with mutable variables beyond that size. Shoot, I have trouble simulating even a handful of classes now, even with full tracing and a debugger. I'd like to see us move past LOC to something like a complexity measurement of the intermediate code or tree form. And on that note, my gut feeling is that none of this even matters. The world's moving towards results-oriented programming, where all that matters is maximizing user satisfaction over cost of development. So acceptance test-driven development (ATDD) should probably be highest priority, then behavior-driven tests (BDD), then unit tests (TDD). On that note, these take at least as long to write as the code itself. I'd even argue that they express the true abstractions of a program, while the code itself is just implementation details. Maybe we should be using user stories implemented per day as the metric.
B008L355 7y ago
Mumps developers only need to write 1 line of code a day
tom_hill 7y ago
Another post currently on the front page has a great example of this: https://news.ycombinator.com/item?id=22306002 https://news.ycombinator.com/item?id=22306002 How do you score this for lines of code per day. ? > I've added 700k lines of code and deleted 747k (yay negative!). Interesting that if you divide the added lines by the 7 years, and figure 250 days/year, he's phenomenally productive 700,00 / 7 / 250 = 400 lines of code per day, sustained over 7 year!
deleted 7y ago
[deleted]
throwaway100x 7y ago
My project at work is 60k LOC, developed over the course of 3 years. It's in production and works quite well. I wrote it all by myself. My hobby project is 100k LOC (2.5 years of development in free time). Both are UI + service code in C++. I code several hours a day. Maybe 3-5 on average. 10 LOC/day is ridiculous. Think about Brad Fitzpatrick, Fabrice Bellard, John Carmack. They would never accomplish anything like they did with those 10 LOC. You have to have dedication and really good text editing skills. Being smart is nothing if you can't write code fast enough. Good skills with tools like shell, debugger, version control are important as well. Another problem is that dev collectives these days tend to bully and punish those with higher performance. There are several reasons for that 1) most devs do an absolute minimum just not to get fired 2) job security is a thing, you won't make your project look too simple or complete as this might end your contract 3) at least 90% of hype is from idiots and by idiots. Idiots are a heavy tax on any engineering 4) frameworks, tools and methodologies are often designed for a different scale 5) ceremonia, overcomplication of development processes, treating devs like anonymous, interchangeable units I'm male in my 40s with a CS degree. I work from home most of the time.
paulajohnson 7y ago
The 10 LOC/day includes the entire project, including analysis, requirements, design, documentation (user and tech), test, management etc, in a large project. Saying (as many do) that an individual programmer has produced hundreds of LOC per day is to miss the point. You have to start by defining your terms of reference and make sure you are comparing like with like.

280 points by rcsorensen 7y ago

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 points. Also, what is up with the random comment about code coverage at the end? That doesnt fit in with the rest of the article either...

ChrisCinelli 7y ago
I am glad I am not the only one to scratch my head...
blauditore 7y ago
It looks like the author is showcasing his product, hence the random screenshot of test coverage as well.
nitwit005 7y ago
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?
- techbio 7y ago
  How do you know how many pixels the ball will take up in a sports photograph before capturing it? Enough to see it, not so many that you can’t see everything else. Same with lines of code, except that instead of a photographer, there is an observing project manager.
marcus_holmes 7y ago
I think they're stuck with the same problem as every dev manager. LoC are pointless/futile/etc, but they're really easy to measure and they're got to measure something right? Like measuring productivity by how many hours people spend at their desks. Utterly pointless, but really easy so it becomes the default measure. Trying to explain to professional managers that there is no foolproof way of measuring developer productivity is a really hard conversation that I've had more than once. I'm assuming the OP's target market is exactly these people, so I don't really blame them for succumbing to the pressure.

dusted 7y ago

Seems 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

edflsafoiewq 7y ago
Empirical proof you wrote refactorable code :)
- dusted 7y ago
  ya, and that they keep changing the requirements.. :)

jammygit 7y ago

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 to code, but 40% less bugs, so faster finish times overall etc)

onion2k 7y ago
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 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.
- mytailorisrich 7y ago
  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.
  - onion2k 7y ago
    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.

bArray 7y ago

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 hard problems - the seriously hard problems. Some of this was figuring out why USB couldn't transition from low-speed mode to high-speed mode reliably (USB is quite hard to probe due to frequency), or figuring out why the application crashed one in a million boots. Some of our most valuable developers committed the least amount of code, but saved our arses more times than I can count.

Bnshsysjab 7y ago
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.
- tomcam 7y ago
  I would love to hear more details on this one
  - erikerikson 7y ago
    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.
    - croon 7y ago
      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.

ww520 7y ago

A good measure is how many lines removed per day.

woutr_be 7y ago
That’s a terrible metric in my opinion. Yes, removing redundant code or optimising code is important, but I wouldn’t want to be judged on it.

fctorial 7y ago

3, take it or leave it.

ChrisCinelli 7y ago

If you are doing a good refactoring, you may have a massive negative LoC at the end. LoC added or removed is not a very good metric for anything. Except if I see a big negative number on a PR, it is usually a great thing. I still have to check what was removed but it usually mean that things are easier to understand.

WalterBright 7y ago
Anytime I see a good chunk of redundant/useless code removed, it's a good day!
- andrewstuart 7y ago
  The greatest, most joyous programming is deleting large chunks of code.

rdiddly 7y ago

Anybody know how he made those treemaps?

supermatt 7y ago
ndepend :) https://www.ndepend.com/docs/treemap-visualization-of-code-metrics https://www.ndepend.com/docs/treemap-visualization-of-code-m...
- rdiddly 7y ago
  a-DOIIIII!! of course

scarejunba 7y ago

Guys, can I be honest? I have never actually met anyone who has worked in a LOC-optimized company. This stuff seems like the outrage porn of software engineering.

taeric 7y ago
Agreed. Worse, I have yet to see someone that gave better estimates than someone that could give a rough "good faith" loc estimate. That is, honestly list out roughly what all code the naive way will touch or generate. Without making assumptions about cheating the metric. If you can bring yourself to that, you can probably give better estimates than you'd expect. Instead, we seem to constantly look for ways to cheat the metric. With no real reason to do so. Other than push the cheating/gaming into a harder sector?
heisenbit 7y ago
You misunderstand the intention. You don't optimize LOC but you develop software as best as you can. You measure - among other things - LOC and this gives you at least some hard figures in the fuzzy software engineering universe. See it as the Hubble constant - it gives you answers about the universe provided you know it's value. Then when it comes to understanding your software costs - it helps you to put some numbers to features. Yes it is dark art but so is all other financial magic. When it comes to maintenance or re-engineering software - LOCs and past numbers can be useful but are not the only determinant of future development costs. There is the agile backlog / planning poker school of thought which is certainly an improvement and valuable running the project but when it comes to large scale software projects it is not an answer I would like to rely on when the project needs a price tag before day one. It is one metric. If you work in any company purely run on metrics - if you ask me - run once you see a better place. If you work in any company not measuring what it does - run now!
- scarejunba 7y ago
  I'm talking about all of these comments on this page with people talking about how LOC/day is not a good metric for productivity. So? No one's tying your wages to LOC/day.

mettamage 7y ago

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.

VectorLock 7y ago
I once had to work with some outsourced developers who would do "something(); something(); something();..." rather than "for(int i = 0; i < 10; i++) something();" when instructed to repeat something X times.
- ascar 7y ago
  It's called loop unrolling and improves performance by eliminating loop control overhead and reducing branch mispredictions. Maybe they had a compiler background :)? /s
  - ktpsns 7y ago
    If they had, they would know that virtually any compiler can do this on his own. I also know these examples and I know the people who are writing them. "Copy & Paste" coding is just more convenient for them instead of writing a loop, fizzling with brackets, indation or whatever. They don't produce high entropy code.
jeen02 7y ago
No way, you're telling me 153 is the same as 315? :O
- mettamage 7y ago
  Yep, it's commutative.
downerending 7y ago
You joke, but I've seen code almost exactly like this in commercial software.

andrewstuart 7y ago

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 pretty meaningless measure but having said that there is at least some truth to it, in that any developer who is writing a typical 21st century application and getting only 10 lines of code per day written, should really examine if they are in the right job.

sampsonitify 7y ago
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 term coding lines per day, versus multi-year coding.
- google234123 7y ago
  Sorry but you won't get much done only writing 10 lines of code per day.
- andrewstuart 7y ago
  >>>People misunderstand it. It means writing code, documentation, testing, bug fixing etc. Are you sure about that? I don't think so. I have not read it for years, but my vague recollection of The Mythical Man Month is that 10 lines a day as a full time professional programmer is a reasonable expectation if you are writing IBM mainframe operating systems in assembly language in the 1970s. It not meant to be saying that hey a programmer is busy with lots of other things like testing documentation etc. Brooks actually meant it, and it was true, at the time, with 1970s hardware, with 1970s development tools, with 1970s collaboration, 1970s compilers/assemblers, 1970s source control, with 1970s level of understanding of computers and software, with 1970s waterfall style project management. And, critically, writing your 10 lines as part of a (relatively speaking) gigantic project for the time. Back then projects did not come much bigger than writing an operating system. Can you imagine trying to get your bit written of some gigantic project where probably no-one has any idea what the fuck is going on, where the source code is, what version is what, who is working on what and how its all meant to tie together. The miracle is that they could get any operating system at all written. Many, many operating system projects failed entirely in the 1970's and 1980's. I'm happy to be proven wrong, cause as I say I haven't read that book for a long long time.

z3t4 7y ago

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.

jspash 7y ago
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.
Sharlin 7y ago
If the code solved the original problem, as understood at the time it was written, then it was not written in vain even if changing requirements or improved understanding eventually make it redundant.
collyw 7y ago
Not at all. If its taking 100 lines to do something and I can rewrite in 10, then that's a lot less places for bugs to hide. That's less than one screen of code for the next person to read / comprehend. In most cases its a win (though I will admit that sometimes comprehension is easier with less concise code).
jariel 7y ago
Accept that it's inherently an iterative process, then you don't think 'sunk cost'. And then 'getting rid of code' is the most wonderful feeling in the world. Getting rid of unneeded code is like clipping toe-nails that are way too long. (It must be done!) It's like cleaning a disgusting floor in the bathroom (it can't wait). It's like fixing ugly grammar and spelling mistakes. It's like sanding and painting that old fence the really needed some attention.
Jtsummers 7y ago
Nope. One of my first experiences with removing many lines of code was in college. It was a compilers project (we had to hand-write it, no YACC or anything). I had written about 10k lines of code in a flurry of activity, and discovered some really gnarly bugs. I spent a day with just a pencil and paper, considering each detail of the algorithms and came up with several key insights which reduced the whole thing to about 1k lines of code. The reduction was a combination of C macros (which I wouldn't use today, but I'd use higher-order functions to accomplish the same thing now) and just smart generic code (no special handling of an add operator versus a multiplication operator, they were both binary operators; differentiating the output for each case happened in one place at the end). That was when I found out I liked deleting code. I'll happily reduce a code base by 90% if the result is clearer and easier to maintain or extend.

Brave-Steak 7y ago

Am I mad? Did anybody actually read the article? Why is everybody piling on LoC/day when the article is about average LoC over a period of time and how it correlates to the work you're doing and what a realistic average LoC might look like for a sane project. From this point of view, it doesn't matter at all if you deleted 20k lines and have a negative LoC for the day. That's missing the forest for the trees.

deleted 7y ago
[deleted]
laichzeit0 7y ago
C’mon man you should know better than that by now. Here on HN you only read the headline. Nobody actually reads the article. At most you read a few comments to get the gist of what people think the article might be about.

jillesvangurp 7y ago

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 lot of people complaining these things are not representative (for the last five decades) but not a whole lot of people coming up with better productivity metrics and even fewer that did the leg work of actually validating their work in something that might pass scientific scrutiny (which is hard). If you do work in this space, you'll find yourself citing articles that are decades old. These days, I tend to look at the activity statistics on github projects when joining a new project. It tells me in a glance of an eye who are the movers and shakers on a project in terms of lines of code added/removed and amount of commits and the time distribution of those commits. It's not perfect and doesn't tell you the complete story but it it's rarely completely wrong. Usually it's quite easy to spot patterns like Weekends, Christmas, vacations, and that people tend to get back energized from a good break (a little spike in productivity). Also these numbers confirm the notion of a 10x programmer: a handful of people tends to be responsible for the vast majority of commits and line changes. Not all software engineers are created equally. Diffstats on pull requests tell me a lot as well; though of course these numbers are inflated by e.g. refactorings (more so on languages that have proper tools for this). But refactoring is a good thing and combined with code reviews tell you a lot about the quality of engineering.

andrewstuart 7y ago
>> 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.
- tfigment 7y 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.

Tade0 7y ago

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.

Insanity 7y ago
That's a pretty big range - but I'd say frontend code tends to be faster / take up more lines. Center a button, give it a colour, make it responsive and you've probably reached your 30 lines of HTML/CSS :P
- nudpiedo 7y ago
  but the fine tuning, bugs and corrections, reported issues and other aspects should be part of the metric too. The days were there i barely progress because some alignment is not working and coordination with the design team is taking the time makes it part of the average as well

dmos62 7y ago

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.

cwingrav 7y ago
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.
- m0zg 7y ago
  I'm consulting a client right now and their C++ codebase is full of gems of this caliber. I eviscerate every single PR, and tell them what's wrong and why, and then their CTO just merges them into master without changing anything. All the while they pay me for it. Why? Fuck me if I know. They hired me to provide advice. I provide advice, and it's pretty expensive. I _know for a fact_ they will regret merging this shit. I can explain why, in a way a toddler would understand. And yet they still do it. Smh.
  - dmos62 7y ago
    You might be going into conflict/criticism mode, which would make them unresponsive. Being right isn't enough to get people to change. I don't know at all if this is the case, just mentioning it, because you seem to be frustrated by the situation.
    - m0zg 7y ago
      I actually asked them if this want me doing this. They said they did. This is only a minor part of what I'm doing for them - my work is mostly on the AI side.

nodomain 7y ago

Shouldn't that article be removed from HN? For me it looks like click bait to promote his nDepend tool.

speleding 7y ago

I'm a 10x programmer, so I do 100 lines per day ;-)

m0zg 7y ago

I wish I had a job where writing 10LOCs per day would be enough. I wrote quarter of a million LOCs at Google alone, and I wasn't the most prolific programmer on the team, not even close. I wrote about as much code since I left Google, too. And it's not Java code either, where your IDE has to crap out 100 lines of boilerplate before you even begin to do anything meaningful. This is mostly C++ and in the last few years Python as well.

pso 7y ago
How long were you at google for, and how long since you left? Otherwise, the numbers don't offer much insight.

magicalhippo 7y ago

I've never found LOC as a useful metric for productivity. Lines of code are most definitely not born equal. So what's this obsession about it? Is it managers who can't or don't want to properly evaluate the performance of the people they're managing?

talkingtab 7y ago

Does anyone else question the mythical man month? If I accept the basic assumption of the mythical man month then I also have to accept that NYC is a myth - there is no way that a city that size can possibly function. Lets start out with ten people in NYC and they add ten more people .... My own belief is the MMM is an apologists view of how we currently collaborate to develop software and products.

ghaff 7y ago
Large organizations function very poorly in a lot of respects. They're also the only way to get a lot of things done. In a lot of ways, it is often a bit surprising to me that large companies can coordinate activities to come out with useful outputs. On the other hand, there are clearly inefficiencies that don't exist with a 10-person startup.
jpalomaki 7y ago
For me the main point in MMM was that big things take time and putting more people to work on the project does not always speed it up. The communication overhead grows exponentially as amount of people increases while the productivity only grows linearly.
Jtsummers 7y ago
What do you question about it? The point of the specific essay was that the work of development/engineering cannot be sped up linearly by adding people. You still see this attitude with managers today: The team of 5 is running behind, let's put that other team on the same project, now it's 10 people. But those 5 new people: 1. Don't know the code base or problem domain. So they'll spend months getting up to speed. 2. Will increase the communication overhead (now each person has to coordinate with up to 9 others, not just 4). On the small scale of this example, you may see good results. 5 more people isn't a huge amount of communication overhead, and if they're experienced (perhaps even formerly worked on the same or similar project) then you'll see an immediate drop in productivity and then a quick rise back to the new baseline. But will that hold with another 10 people? 20 more beyond that? Each doubling will not continue to halve the time to develop the project, there are limits, and at some point the returns will be negative. The additional people will slow it down. Not just the initial slow-down, but also the new baseline after things settle will be lower than before adding them.

grumple 7y ago

Web devs: don't think this applies to you. If you're pushing up 0 lines of code on a day where you had no meetings or interruptions, and you aren't working on something truly novel and near-impossible, you took the day off on the company dime. And everybody you worked with noticed, and if you do it regularly - they are just waiting for everybody to reach their breaking point with you so they can push to get rid of you. Sure, you'll find a new job and do it again, but you'll still not have anybody's respect.

timwaagh 7y ago
This is why people push the most difficult tasks to the most junior developers. Because a dev stuggling to do the 'impossible' looks the exact same way. That way others get to protect themselves from blame.
- grumple 7y ago
  > This is why people push the most difficult tasks to the most junior developers. Who does that? The correct thing is to manage expectations and then do the work. Unfortunately there are many lazy developers (or people in any sort of job) who won't be productive with even the most simple tasks.
qntty 7y ago
thx mom

shultays 7y ago

sounds like I am at least a 10x programmer

collyw 7y ago

Personally I take more pride in removing code these days.

antirez 7y ago

I did some trivial math. Redis is composed of 100k lines of code, I wrote at least 70k of that in 10 years. I never work more than 5 days per week and I take 1 month of vacations every year, so assuming I work 22 days every month for 11 months: 70000/(22*11*10) = ~29 LOC / day Which is not too far from 10. There are days where I write 300-500 LOC, but I guess that a lot of work went into rewriting stuff and fixing bugs, so I rewrote the same lines again and again over the course of years, but yet I think that this should be taken into account, so the Mythical Man Month book is indeed quite accurate. However this math is a bit off because in the course of such 10 years I wrote quite a number of side projects, but still, max ~50 LOC / day.

esotericn 7y ago
From the sounds of it that also includes a decent amount of greenfield work. I don't have hard figures to easily consult but I'd guess that I'm at about your average in total, but then on the days when I'm refactoring/debugging existing stuff, honestly it could be like 3 lines a day, or 5, or just planning/sketching something out. It's like the old mechanic trope. It's not hard to replace a bolt, what's hard is knowing which bolt to replace and where.
- mumblemumble 7y ago
  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-documented, easy to understand, and backed by tests that make the intended behavior clear? Or do I have to start by burning days or weeks on wrangling with Chesterton's Fence?" And, on the other side of it, when is documenting and cleaning my own code to guard some future maintainer from that situation vital, and when am I burning a day of my own time to save someone else only an hour in expectation? All I know for sure in that situation is that, if my manager is assiduously counting LOC, ticket close rate, anything like that, then game theory demands that 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. The 10X rockstar developer at a previous team of mine taught me that lesson in a rather brutal manner.

not_buying_it 7y ago

lol I average about 200 a day, guess I'm not a pro:(

thrower123 7y ago

I'm not sure I add 10 lines of code, on average, to our products a day. Most days are probably negative, to be honest. Of course, any time I have to add a new Windows Forms dialog to our install/config utility, there's a couple thousand lines of code-behind added to the repo...

hermitcrab 7y ago

I did some analysis of my own projects and came up with around 50 LOC per day: https://successfulsoftware.net/2017/02/10/how-much-code-can-a-coder-code/ https://successfulsoftware.net/2017/02/10/how-much-code-can-... But: -As a 1-man-band I also do the support, documentation, testing, website, marketing etc. So coding is only part of what I do. -I don't think the article defines what a LOC is. Does it include headers? Does it include auto generated code?

eeZah7Ux 7y ago

A good bricklayers places MORE bricks in a day than others. A good construction engineer builds a house using LESS concrete that others. I'd rather be a good software engineer than a "x10 developer".

toadi 7y ago

This is still a thing... working in the field for 20 years and really is 15 years ago LOC as KPI went away... Why is it back?

iamaelephant 7y ago

This is just an ad for NDepend.

cpascal 7y ago

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.

Cpoll 7y ago
I wonder if LOC changed isn't often reversely proportional to time taken. 500 LOC feature: Add a new route that does something boring; 5 story points. 5 LOC feature: Fix mysterious performance degradation in X; 13 story points.
- cpascal 7y ago
  I think for defect estimation you are right, but for feature estimation (new code, not fixing bad code) the correlation is positive.

Koshkin 7y ago

Well, this depends on the language. I once wrote 12,000 lines of x86 assembly code in four (long) days.

zackmorris 7y ago

We should probably be using the absolute value of lines of code, so abs(LOC) as the metric, or something like a least squares mean for estimating the moving average of LOC per day. Anymore, my daily average LOC is probably negative since I tend to rescue floundering projects. I usually avoid object-oriented (OO) programming whenever possible, as I've found that functional one-shot code taking inputs and returning outputs, with no side effects, using mostly higher order functions, is 1 to 2 orders of magnitude smaller/simpler than OO code. Also I have a theory that OO itself is what limits most programs to around 1 million lines of code. It's because the human mind can't simulate the state of classes with mutable variables beyond that size. Shoot, I have trouble simulating even a handful of classes now, even with full tracing and a debugger. I'd like to see us move past LOC to something like a complexity measurement of the intermediate code or tree form. And on that note, my gut feeling is that none of this even matters. The world's moving towards results-oriented programming, where all that matters is maximizing user satisfaction over cost of development. So acceptance test-driven development (ATDD) should probably be highest priority, then behavior-driven tests (BDD), then unit tests (TDD). On that note, these take at least as long to write as the code itself. I'd even argue that they express the true abstractions of a program, while the code itself is just implementation details. Maybe we should be using user stories implemented per day as the metric.

B008L355 7y ago

Mumps developers only need to write 1 line of code a day

tom_hill 7y ago

Another post currently on the front page has a great example of this: https://news.ycombinator.com/item?id=22306002 https://news.ycombinator.com/item?id=22306002 How do you score this for lines of code per day. ? > I've added 700k lines of code and deleted 747k (yay negative!). Interesting that if you divide the added lines by the 7 years, and figure 250 days/year, he's phenomenally productive 700,00 / 7 / 250 = 400 lines of code per day, sustained over 7 year!

deleted 7y ago

[deleted]

throwaway100x 7y ago

My project at work is 60k LOC, developed over the course of 3 years. It's in production and works quite well. I wrote it all by myself. My hobby project is 100k LOC (2.5 years of development in free time). Both are UI + service code in C++. I code several hours a day. Maybe 3-5 on average. 10 LOC/day is ridiculous. Think about Brad Fitzpatrick, Fabrice Bellard, John Carmack. They would never accomplish anything like they did with those 10 LOC. You have to have dedication and really good text editing skills. Being smart is nothing if you can't write code fast enough. Good skills with tools like shell, debugger, version control are important as well. Another problem is that dev collectives these days tend to bully and punish those with higher performance. There are several reasons for that 1) most devs do an absolute minimum just not to get fired 2) job security is a thing, you won't make your project look too simple or complete as this might end your contract 3) at least 90% of hype is from idiots and by idiots. Idiots are a heavy tax on any engineering 4) frameworks, tools and methodologies are often designed for a different scale 5) ceremonia, overcomplication of development processes, treating devs like anonymous, interchangeable units I'm male in my 40s with a CS degree. I work from home most of the time.

paulajohnson 7y ago

The 10 LOC/day includes the entire project, including analysis, requirements, design, documentation (user and tech), test, management etc, in a large project. Saying (as many do) that an individual programmer has produced hundreds of LOC per day is to miss the point. You have to start by defining your terms of reference and make sure you are comparing like with like.