24 ms·

-2000 Lines of Code (2004)

332 points by pvillano 4y ago

pfoof 4y ago
So that's why Git shows both + and - numbers. Either way, with such management...
- KerrAvon 4y ago
  Oh, there’s definitely value in seeing that in a PR diff. I don’t think that’s a management thing per se.
deleted 4y ago
[deleted]
tootie 4y ago
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” - Bill Gates
- lelandfe 4y ago
  That's one of the most effective analogies I have ever heard. Will be reusing, thanks.
  - hinkley 4y ago
    There’s an old aerospace joke about how the cost per pound of airplane equipment has been continuously going up and at some point the only way to maintain the line is if some of the equipment weighed 0 lbs. Hence the introduction of software.
kbenson 4y ago
I imagine this is in response to the rumors that Twitter employees had to print out the code changes they did in the last month to justify their jobs. This, and stories like it, are what I thought of when I heard that.
- YZF 4y ago
  They should print out the diff ;)
  - jspash 4y ago
    Or bump up the font, increase the margins and leading. It worked for my high-school book reports! 4 pages? No problem.
- samatman 4y ago
  Has there been any definitive reporting on this? What I remember reading on Twitter at the time, was that devs were expected to print out about fifty pages of diffs relevant to the last six months of their work. Rather than printing out all changes from the last month. The printout part makes me question the idea that code was being counted. That part is easy to do with tools which Twitter undoubtedly has. I've never worked a job where I couldn't print out 50 pages of diffs for six months, although I have the sort of temperament where I'd probably sandbag or quit if asked to. There's little point in speculating on this until a clear picture emerges. I can't imagine a winnowing process for a new takeover that didn't involve some kind of portfolio justifying the worker's salary. Not at Twitter, which was notoriously overstaffed and had a reputation for rest-and-vest.
  - phire 4y ago
    > Has there been any definitive reporting on this? I'm not aware of any such reporting, just rumours. But it seems obvious that since they scrapped together this list in just a single week, they can't have done anything much more complex than use some simple metrics.
KerrAvon 4y ago
LOC is the refuge of the incompetent. At Apple, when Gil Amelio came on board with Ellen Hancock etc, one of the first things they asked for was a total LOC estimate for Copland. There was a lot of pushback because engineering knew it was meaningless but they said they wanted it anyway. I don’t know what they did with it. The ex-NeXT management who took over from them never asked for LOC.
- vbezhenar 4y ago
  For me LoC is a good initial metric. I don't know why everyone refuses it outright. Yes, there're cases where someone will spend month just to delete 1 line and that would be productive. Or when someone will autogenerate 10k LoC spending 5 minutes. But keeping it in mind I still use LoC as initial metric when I need to estimate PR complexity or project complexity. I guess it should not be the only metric and it definitely should not be the metric which is used to estimate someone's productivity, at it's very easily gamed. It's good because I need few shell commands to measure it.
  - njharman 4y ago
    There're tools that analyse and report on code's actual complexity. Using, ya know science.
    - LtWorf 4y ago
      There is more to complexity than how nested something is.
    - fragmede 4y ago
      Can you name some? I'd be interested in trying them out. For, y'know, science.
  - fragmede 4y ago
    Because it's so obviously easily gamed. There are some very specific contexts in which LoC is actually useful. A codebase with 1M LoC is vastly different to deal with than one with 100,000, no matter the language. Goodhart’s Law: when a measure becomes a target, it cease to be a good measure.
dang 4y ago
Related: -2000 Lines of Code - https://news.ycombinator.com/item?id=26387179 https://news.ycombinator.com/item?id=26387179 - March 2021 (256 comments) -2000 Lines of Code - https://news.ycombinator.com/item?id=10734815 https://news.ycombinator.com/item?id=10734815 - Dec 2015 (131 comments) -2000 lines of code - https://news.ycombinator.com/item?id=7516671 https://news.ycombinator.com/item?id=7516671 - April 2014 (139 comments) -2000 Lines Of Code - https://news.ycombinator.com/item?id=4040082 https://news.ycombinator.com/item?id=4040082 - May 2012 (34 comments) -2000 lines of code - https://news.ycombinator.com/item?id=1545452 https://news.ycombinator.com/item?id=1545452 - July 2010 (50 comments) -2000 Lines Of Code - https://news.ycombinator.com/item?id=1114223 https://news.ycombinator.com/item?id=1114223 - Feb 2010 (39 comments) -2000 Lines Of Code (metrics == bad) (1982) - https://news.ycombinator.com/item?id=1069066 https://news.ycombinator.com/item?id=1069066 - Jan 2010 (2 comments)
- slantedview 4y ago
  The difference between those posts and this one is context, since in the past week we've seen LoC being used as a metric to determine mass layoffs at a prominent tech company.
  - marcosdumay 4y ago
    > since in the past week we've seen LoC being used as a metric to determine mass layoffs at a prominent tech company. Do we actually know that? People were asked to print their code, and a mass layoff happened. But AFAIK, what feature of the code was judged (if any) is kept as a secret.
- tonnydourado 4y ago
  Well, it is a damn good story. People might have gone overboard on 2010, but every 18 months seems like an acceptable rate, to get new people introduced to the tale =)
  - dang 4y ago
    Oh yes. The purpose of 'related' lists to give people more (hopefully) interesting stuff to read—not to scold anybody! Reposts are fine after a year or so (this is in the FAQ: https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html) and for classics and perennials, occasional reposts are important so more recent cohorts of users can get to know the culture (https://news.ycombinator.com/item?id=32405060 https://news.ycombinator.com/item?id=32405060).
hinkley 4y ago
Gave myself an RSI writing -500 LOC in vi. Only discovered the block indent instruction partway through. It was copypasta of a bad n² idiom for collision detection between two search criteria. So first I had to replace it all with a function, then change the function. Made the app actually usable though.
Tempest1981 4y ago
I assume the purpose of the form was to quantify the size of the change, to gauge the risk involved, and the QA effort required. Is there a better way to gauge "churn" or risk? Cyclomatic complexity deltas?
kjksf 4y ago
I'm not saying that measuring programmer's productivity by lines of code written is good. This story, however, is not a story of someone who deleted 2k lines of code. It's story of someone who wrote, let's ballpark, 4k lines of code and then rewrote them, which resulted in 2k lines of code left. Not sure how to account for that but let's say it's 5k lines of new code written in total which ended up as 2k loc. This story does not prove that you are a great programmer if you write little code. It actually shows that even the best of the best (like Bill Atkinson) write a lot of code and cannot arrive at the ideal code at the first try. Writing the first 4k loc was a necessary step to gain knowledge that enabled him to refactor the code down to 2k loc.
- pjc50 4y ago
  It doesn't specify whether _he_ wrote the 4kloc first .. Negative LOC is not uncommon in maintenance work; things become obsolete or better solutions are invented.
  - pencilguin 4y ago
    He did. Or anyway the first version. Possibly other people dirtied it after.
    - Izkata 4y ago
      Doesn't really matter either way, article indicates the report the -2000 was put on was from a restricted time range.
  - Olumde 4y ago
    Steve Balmer on IBMs obsession with KLOCS https://www.youtube.com/watch?v=kHI7RTKhlz0 https://www.youtube.com/watch?v=kHI7RTKhlz0
- pdpi 4y ago
  For one of the most frustrating projects I ever worked on, my net contribution was in the vicinity of -1k to -2k LOC in a service that weighed in at around ~5k LOC in the end. The guy who started the project came from an enterprise Java background, and his code was the stereotypical design pattern pileup. I only jumped in because he was having trouble actually wrapping it up, and, with every commit, I deleted a bunch of code and replaced it with just a small fraction of what was there before, and he reviewed the changes and agreed they were an improvement. Yet, even though he genuinely agreed his code was overly complicated, he never internalized the learnings, and kept repeating the same mistakes over and over again. He was fixated on the idea that his coded needed to be extensible (without a clear notion of how or why) and kept adding abstraction after abstraction for every new feature he added. So, yes. It is uncontestably true that you often need to write 4k LOC before you understand how to write the same thing in 2k LOC. But it's also very much the case that there's a baseline of skill you need to write those 4k LOC instead of a 10k monstrosity.
hprotagonist 4y ago
My favorite PRs of late have come in at numbers like +280/-1257. (I replaced a lot of janky flask handholding with the equivalent fastapi machinery, to much joy.)
gcanyon 4y ago
I like this one almost as much as "And then he discovered loops!" https://www.folklore.org/StoryView.py?project=Macintosh&story=Discovered_Loops.txt https://www.folklore.org/StoryView.py?project=Macintosh&stor... I use the loops one more often in discussing development.
Wowfunhappy 4y ago
Allow me to play devil's advocate for a moment: Most good writers will tell you that shorter is almost always better. You want to express your thoughts in the most succinct way possible. Review your own writing to remove as much as you can, then hand your draft off to an editor who'll try to cut even more. And yet, many writers are still paid by the word, and many book contracts still specify target page counts. Because even though shorter is better, the shortest possible length of a given text still serves as a rough measure of that text's breath and complexity. Is code any different? Yes, paying or evaluating programmers by lines of code is going to lead to misaligned incentives. However, I'm not convinced the dynamic is any worse than for prose. Bill Atkinson spent a week removing extraneous code from QuickDraw; an author might spend a week cutting extraneous subplots from a novel. Word count is still a useful metric for the author. Perhaps the difference is that non-writers tend to be more familiar with the writing process than non-programmers are with coding. If an author was working on revising a novel, no one would ask them how many words they'd written that week. Or maybe word count measurements are in fact making everyone's prose worse and we should do away with them too.
- BlargMcLarg 4y ago
  The code is different in the sense that good abstractions and function definitions, when not used in excess, will severely cut down the amount of lines. However, given the same amount of time and not a lot of time spent on thinking about abstractions, odds are they will end up with fairly similar LoC counts. Just developer A will have written more features, whereas developer B will have done the same thing over and over, without having the same features. That's where your example of writers should take hold too: good writers stop being paid by the word and start being paid by number of sales. The same should be done with devs. That said, the entire thing gets tossed out of the window when considering significant portions of developers will overthink abstractions, fiercely hold onto overabstractions (which end up bloating LoC), have discussions with each other ad nauseam, slow down code reviews over petty differences, and more.
  - skrtskrt 4y ago
    Also if you write an abstraction then your teammates use it, the measurement on either you or your teammates or both is going to be skewed whether you’re going for high or low LoC. If
deleted 4y ago
[deleted]
grensley 4y ago
I would love love love to see a study on the correlation between lines of code (not net, total changes + and -) and co-worker assessment of aptitude for people in the non-inclusive band from Junior to Architect (aka, people who are really expected to write a bulk of the software).
sdeframond 4y ago
I light of recent Twitter events, I wonder what Musk would think of this...
- bheadmaster 4y ago
  Is there any evidence that Musk is evaluating Twitter employees based on the LoC written? There's been so much fake news regarding Twitter and Musk these days that I honestly can't tell anymore.
  - sillysaurusx 4y ago
    I had the same thought. It’s one of those stories that we’d love to believe, just because it’s so incendiary. But the original source seemed to be an unsourced tweet, and it’s not a good idea to believe those. I’d be interested in evidence too.
  - sdeframond 4y ago
    > Is there any evidence that Musk is evaluating Twitter employees based on the LoC written? I've seen in the news that Musk asked devs to print their code for review by Tesla engineers. Not that their LoC would be counted strictly speaking. Now is this piece of news even true?
PragmaticPulp 4y ago
No metric can or should be used in isolation to evaluate productivity. LOC is obviously very flawed, but to be completely honest it has been useful as part of a heuristic for figuring out where something has gone wrong in a department (after applying basic heuristics like removing packaged code, vendored stuff, etc.) For example, if engineers are constantly committing and then deleting huge amounts of code (somewhat like this example) then it’s good to dive in and make sure you don’t have some issues creating that situation. This can range from product managers who aren’t validating their requests before engineers start working on them, to interpersonal issues such as unqualified juniors writing large amounts of buggy code and leaving it for senior engineers to fix. These metrics can also be warning signs that something has gone wrong. If an engineer’s number of commits have plummeted and LOC committed has gone way down, it’s a sign that you should ask more deeply how their work is going. I’ve had situations where programmers were being pulled into 20+ hours of meetings each week and being given weird research assignments from random C-level executives that took away all of their coding time. I’ve also had situations where people weren’t getting along with each other in private and DMs, and the first warning sign was that their contributions stalled. So while LOC and commit metrics can absolutely be misinterpreted in the wrong hands (e.g. as a proxy for laying off Twitter employees without trying to understand the context of their work) I’ve actually found them to be helpful as one of several early warning systems that something is going wrong with a team or project. Work with people for a while and it’s not hard to recognize their normal output and when it has stalled for unexpected reasons. Use that as a signal to start a conversation about how they’re doing.
- nonethewiser 4y ago
  I setup prettier and ran it against our codebase. Guess I'm the CTO now.
choeger 4y ago
But he didn't write -2000 lines of code, did he? He wrote a new algorithm that was 2000 lines shorter than the old one. So, in principle, there was a positive number of lines that could have been reported. Of course, loc is a bad goal for productivity, but it can still be an interesting measure (similar to test coverage): If I count lines of code added, commits, or tickets closed, I cannot compare any two developers. But if I count that metric for the same developer, or the same team, I can certainly spot changes in productivity. (As every metric has its outliers it would probably be. best to combine all of them.) So if I was managing a team and wanted to know if it would be beneficial to optimize test execution times, I could just rent some bigger machines and see what happens. I could also do a similar experiment with organizational aspects like the size and schedule of meetings or the introduction of a dedicated on-call contact for support requests, etc.
- SonOfLilit 4y ago
  No, you can't. There is barely any correlation between the amount of new lines of code I wrote in a day and how productive I was that day. As a senior technologist who bills his time as a consultant, I can tell you that I (correctly) get paid the most for days where I write 0 lines of code. But also, my most valuable code was code where I spent a week thinking and writing maybe 5 lines of code a day, and my least valuable code was when my output was limited by my typing speed.
  - ShredKazoo 4y ago
    Alternative proposal: Count the number of commits devs are making. Since some devs make more frequent commits than others, for each dev review some fraction of their commits at random, and rate how substantial the randomly sampled commits are. Then multiply average commit importance by number of commits to get an overall productivity score. Thoughts? I think the biggest counterargument is that it incentivizes churn like making a commit and then reverting it later.
    - BlargMcLarg 4y ago
      Your ratings are going to be somewhat arbitrary and the moment this comes out, you'll risk Goodhart's Law anyway. Besides, you might as well start counting closed number of issues/tasks/tickets, story points or whatever, and skip the commit count altogether.
msoad 4y ago
I know lines of code as a measure of productivity has been criticized to death here and elsewhere but today I went and did some analysis on past two years of my team members contributions and saw the team members that I know they are productive are modifying code a ton more than others. It can be subtraction of code too but overall more changes correlated with my perception of their contributions. My perception is pretty informed because I'm their manager and I know this team and this code base very well.
- johannes1234321 4y ago
  Amount of code can be an indicator, however as soon as developers know it is being used as metric it is easy to manipulate.
  - AnonCoward42 4y ago
    "When a measure becomes a target, it ceases to be a good measure." (short form of Goodhart's law)
  - expazl 4y ago
    No, it's not easy to manipulate. You're thinking in linear terms which isn't what lines of code changed is useful as. You can't use it to distinguish which of 4 different productive programmers is most or least productive. However it's extremely easy to distinguish the non-productive programmer in the group of 5. And it's not easy to fake, because as soon as that developer start merging in a ton of bogus or useless edits to push up their numbers then everyone on the team, including the manager will call them on their bullshit. It's just like shift times for workers in manual labor jobs. You can't tell which of the people who are meeting up 8 hours a day is most productive based on if they where there for 8 hours and 12 minutes or 8 hours and 25 minutes. But you sure as hell can easily see that if someone is showing up 4-5 hours on a nine-to-five job, then something is wrong. And if that person tries to "fake it" but showing up for 8 hours but spends half the time slacking off, but coworkers and managers will call him on the bullshit.
    - BlargMcLarg 4y ago
xyzzy4747 4y ago
Of the several engineers I've managed at my startup, the ones who wrote the most code got the most stuff done. It's a correlation and there are exceptions, but it's generally the case, at least for new software. A project won't complete itself without a lot of code being written or modified. Although I think total number of PRs is possibly more useful as a metric than total LOC (assuming neither are being gamed).
- LtWorf 4y ago
  I know people who write quickly huge amounts of very poorly thought of code that will be buggy and will have a bunch of completely useless functions, reimplemented functions that already existed within the project and similar stuff. You might be unaware that you are not such a great manager.
- startupsfail 4y ago
  This is sometimes true for early stage projects. There are exceptions, sometimes you can have an engineer creating a library or a framework without any need. An existing library would have done a better job faster, but that engineer just wanted to make a new one. As a result you can have a massive framework, known only by that engineer in which that engineer is very effective. But no one else is. And overall it is a liability, if compared to an existing framework. In general, the more code you have the more code you have to maintain and massive codebase churned out by a single engineer is more often a liability, not an asset.
slantedview 4y ago
I love that 40 years later, a prominent tech company leader still has yet to learn the lesson of this story.
- pjc50 4y ago
  People love reasoning things from first principles rather than learning.
  - sixstringtheory 4y ago
    Isn’t reasoning things from first principles exactly how you learn? I think what you meant was that people love learning lessons the hard and slow way instead of taking others’ word for it. I’m sort of conflicted on this. Yes, it is faster to take an expert’s word for it. But after a couple of human generations of that, do we actually lose understanding? I think we can only stand on the shoulders of giants standing on the shoulders of giants to some N giants until the whole acrobatic totem pole comes tumbling down. The game of telephone through the ages produces belief, not understanding. Another option is making giants more giant, but that is an even slower process than one person learning from first principles: humanity has to find a way for our brains to learn those principles faster. Maybe that will take millions of years of evolution. Or maybe something like neuralink will provide a shortcut so it only takes thousands of years.
  - _dain_ 4y ago
    people also love getting filthy fucking rich, how's that working out for you?
ihateniggas 4y ago
mepiethree 4y ago
There are any number of counter examples to most of these metrics, but I think the extreme counter examples are often in bad faith. You can’t convince me that a JavaScript engineer who consistently authors 1 commit a month is productive. At some point, you need to stop talking about stuff and actually build stuff Of course you can’t determine the best person by lines of code (package.lock files lol) but you can often make a guess at the worst person
- lanstin 4y ago
  If they mostly are telling other people what to do to make the other people write better code, then yeah, they can be productive to the work of the company. In a good job, I will save more time by tweaking other peoples plans than any direct execution I do. There is a reason the best management is management by walking around, talking to people, finding it what is actually going on.
  - dbish 4y ago
    That’s a manager then, not a software engineer/developer role if your whole job is directing others and not doing any coding yourself, and I’d posit that if you are doing that for too long, you probably shouldn’t be tweaking anyone else’s code eventually since you will lose touch with the system if you aren’t coding and your advice shouldn’t be at the program level anymore.
    - lanstin 4y ago
      Not if your job is only to make people better programmers, not responsible for product deliveries but responsible to code quality, code brevity, long term maintainability, that sort of thing. If you keep pairing with people and pointing out better ways of doing things, ways of doing things that they might have considered impossible but have some hackish solution of a category they haven’t used before, or of building things towards your desired long term plans but not specifically asked for by product/customers, the job is only code and coding, but also enculturation of a group into a common vision that can make for very high performing groups of developers.
cathdrlbizzare 4y ago
Dead Code Society ftw
anonymousiam 4y ago
Seems like whenever I write a bunch of code, it's always bigger before I've completed the test/debug phase. I put this down to revisiting all the algorithms while finalizing the code, and making adjustments/optimizations where it makes sense.
- ChrisMarshallNY 4y ago
  I do a lot of that. Also, when I review the code documentation. I will sometimes, completely rewrite methods.
andirk 4y ago
How about get to know your team and it becomes very obvious who is more productive. If you need a metric for, say, large teams, how about: # PRs x level of effort, + bonus points for being useful outside of code. Great engineers are like a 5'10" [attractiveness redacted] [hair color redacted] [gender redacted]; it's very obvious, isnt it??
jspash 4y ago
The first thing I look at when reviewing a pull request is the total lines of code added and removed. If the number is over a certain amount (it differs depending on the language and task) I will immediately reject it and ask for a one-on-one. Too many additions or deletions are a signal that something went wrong somewhere. Either the dev went off piste or the task wasn't properly specified. Or sometimes an auto-formatter has gone on the fritz and "prettiered" everything up.
mrjin 4y ago
That was almost exactly what happened to me a couple of years ago. The company hired a terrible guy with an architect title. What he did was some really simple 3rd party integration sending some transaction details to an accounting provider. Instead of reading from db, he decided to intercept those before saving to db coz some of those were not saved at all (only a problem for accounting, but most of the customers did not use accounting providers anyway). So, he spent over a year on that and moved on to another project. I took the project over and lots of complaints from beta testing customers. My manager and I spoke to him about it and never get anywhere. "Look, I can spend another year on this, and it might never really work. How about let me scrap his sh*t and start over?" I proposed. Months later, green light I got. So I deleted all his code solely for that part, around 5k lines and replaced with merely ~300 lines, never had an issue since then. Soon we hired a new Product Lead, the first thing he did was asking how many lines code we wrote in the past year. Errr, okay, so I pulled out stats from source control. Ouch, it was minus ~3k lines.
mark_undoio 4y ago
I like to call this "net negative development"! Valuable contributions to an established codebase can involve a tiny amount of code but a massive amount of understanding, so it's easy for a developer to clean up more in old code than they add in new code. There must be a point where this doesn't hold as well - new feature projects or, especially, newer projects themselves - where adding code is more correlated with value.
SergeAx 4y ago
Once on the interview in the part "what do you want to know about the company and our team" candidate asked me what kind of new code my best engineers are adding to the codebase. Almost immediately I answered that the best engineers here are mostly removing code, because it is much harder problem.
ibbtown 4y ago
I'm sure it was a unsigned integer. So probably he made a record :)
aaron695 4y ago
deleted 4y ago
[deleted]
anonu 4y ago
You pay good developers for the lines of code they do not write.
michaelcampbell 4y ago
I've been a developer professionally since the mid 80's, and working for other people since the early 90's, and never once have I ever seen LOC used for anything but code reviews where "lines per function" had an upper limit. Never heard of anyone using it, nor worked with anyone who encountered it as described. Where are these LOC counting managers I hear so much about?

332 points by pvillano 4y ago

pfoof 4y ago

So that's why Git shows both + and - numbers. Either way, with such management...

KerrAvon 4y ago
Oh, there’s definitely value in seeing that in a PR diff. I don’t think that’s a management thing per se.

deleted 4y ago

[deleted]

tootie 4y ago

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” - Bill Gates

lelandfe 4y ago
That's one of the most effective analogies I have ever heard. Will be reusing, thanks.
- hinkley 4y ago
  There’s an old aerospace joke about how the cost per pound of airplane equipment has been continuously going up and at some point the only way to maintain the line is if some of the equipment weighed 0 lbs. Hence the introduction of software.

kbenson 4y ago

I imagine this is in response to the rumors that Twitter employees had to print out the code changes they did in the last month to justify their jobs. This, and stories like it, are what I thought of when I heard that.

YZF 4y ago
They should print out the diff ;)
- jspash 4y ago
  Or bump up the font, increase the margins and leading. It worked for my high-school book reports! 4 pages? No problem.
samatman 4y ago
Has there been any definitive reporting on this? What I remember reading on Twitter at the time, was that devs were expected to print out about fifty pages of diffs relevant to the last six months of their work. Rather than printing out all changes from the last month. The printout part makes me question the idea that code was being counted. That part is easy to do with tools which Twitter undoubtedly has. I've never worked a job where I couldn't print out 50 pages of diffs for six months, although I have the sort of temperament where I'd probably sandbag or quit if asked to. There's little point in speculating on this until a clear picture emerges. I can't imagine a winnowing process for a new takeover that didn't involve some kind of portfolio justifying the worker's salary. Not at Twitter, which was notoriously overstaffed and had a reputation for rest-and-vest.
- phire 4y ago
  > Has there been any definitive reporting on this? I'm not aware of any such reporting, just rumours. But it seems obvious that since they scrapped together this list in just a single week, they can't have done anything much more complex than use some simple metrics.

KerrAvon 4y ago

LOC is the refuge of the incompetent. At Apple, when Gil Amelio came on board with Ellen Hancock etc, one of the first things they asked for was a total LOC estimate for Copland. There was a lot of pushback because engineering knew it was meaningless but they said they wanted it anyway. I don’t know what they did with it. The ex-NeXT management who took over from them never asked for LOC.

vbezhenar 4y ago
For me LoC is a good initial metric. I don't know why everyone refuses it outright. Yes, there're cases where someone will spend month just to delete 1 line and that would be productive. Or when someone will autogenerate 10k LoC spending 5 minutes. But keeping it in mind I still use LoC as initial metric when I need to estimate PR complexity or project complexity. I guess it should not be the only metric and it definitely should not be the metric which is used to estimate someone's productivity, at it's very easily gamed. It's good because I need few shell commands to measure it.
- njharman 4y ago
  There're tools that analyse and report on code's actual complexity. Using, ya know science.
  - LtWorf 4y ago
    There is more to complexity than how nested something is.
  - fragmede 4y ago
    Can you name some? I'd be interested in trying them out. For, y'know, science.
- fragmede 4y ago
  Because it's so obviously easily gamed. There are some very specific contexts in which LoC is actually useful. A codebase with 1M LoC is vastly different to deal with than one with 100,000, no matter the language. Goodhart’s Law: when a measure becomes a target, it cease to be a good measure.

dang 4y ago

Related: -2000 Lines of Code - https://news.ycombinator.com/item?id=26387179 https://news.ycombinator.com/item?id=26387179 - March 2021 (256 comments) -2000 Lines of Code - https://news.ycombinator.com/item?id=10734815 https://news.ycombinator.com/item?id=10734815 - Dec 2015 (131 comments) -2000 lines of code - https://news.ycombinator.com/item?id=7516671 https://news.ycombinator.com/item?id=7516671 - April 2014 (139 comments) -2000 Lines Of Code - https://news.ycombinator.com/item?id=4040082 https://news.ycombinator.com/item?id=4040082 - May 2012 (34 comments) -2000 lines of code - https://news.ycombinator.com/item?id=1545452 https://news.ycombinator.com/item?id=1545452 - July 2010 (50 comments) -2000 Lines Of Code - https://news.ycombinator.com/item?id=1114223 https://news.ycombinator.com/item?id=1114223 - Feb 2010 (39 comments) -2000 Lines Of Code (metrics == bad) (1982) - https://news.ycombinator.com/item?id=1069066 https://news.ycombinator.com/item?id=1069066 - Jan 2010 (2 comments)

slantedview 4y ago
The difference between those posts and this one is context, since in the past week we've seen LoC being used as a metric to determine mass layoffs at a prominent tech company.
- marcosdumay 4y ago
  > since in the past week we've seen LoC being used as a metric to determine mass layoffs at a prominent tech company. Do we actually know that? People were asked to print their code, and a mass layoff happened. But AFAIK, what feature of the code was judged (if any) is kept as a secret.
tonnydourado 4y ago
Well, it is a damn good story. People might have gone overboard on 2010, but every 18 months seems like an acceptable rate, to get new people introduced to the tale =)
- dang 4y ago
  Oh yes. The purpose of 'related' lists to give people more (hopefully) interesting stuff to read—not to scold anybody! Reposts are fine after a year or so (this is in the FAQ: https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html) and for classics and perennials, occasional reposts are important so more recent cohorts of users can get to know the culture (https://news.ycombinator.com/item?id=32405060 https://news.ycombinator.com/item?id=32405060).

hinkley 4y ago

Gave myself an RSI writing -500 LOC in vi. Only discovered the block indent instruction partway through. It was copypasta of a bad n² idiom for collision detection between two search criteria. So first I had to replace it all with a function, then change the function. Made the app actually usable though.

Tempest1981 4y ago

I assume the purpose of the form was to quantify the size of the change, to gauge the risk involved, and the QA effort required. Is there a better way to gauge "churn" or risk? Cyclomatic complexity deltas?

kjksf 4y ago

I'm not saying that measuring programmer's productivity by lines of code written is good. This story, however, is not a story of someone who deleted 2k lines of code. It's story of someone who wrote, let's ballpark, 4k lines of code and then rewrote them, which resulted in 2k lines of code left. Not sure how to account for that but let's say it's 5k lines of new code written in total which ended up as 2k loc. This story does not prove that you are a great programmer if you write little code. It actually shows that even the best of the best (like Bill Atkinson) write a lot of code and cannot arrive at the ideal code at the first try. Writing the first 4k loc was a necessary step to gain knowledge that enabled him to refactor the code down to 2k loc.

pjc50 4y ago
It doesn't specify whether _he_ wrote the 4kloc first .. Negative LOC is not uncommon in maintenance work; things become obsolete or better solutions are invented.
- pencilguin 4y ago
  He did. Or anyway the first version. Possibly other people dirtied it after.
  - Izkata 4y ago
    Doesn't really matter either way, article indicates the report the -2000 was put on was from a restricted time range.
- Olumde 4y ago
  Steve Balmer on IBMs obsession with KLOCS https://www.youtube.com/watch?v=kHI7RTKhlz0 https://www.youtube.com/watch?v=kHI7RTKhlz0
pdpi 4y ago
For one of the most frustrating projects I ever worked on, my net contribution was in the vicinity of -1k to -2k LOC in a service that weighed in at around ~5k LOC in the end. The guy who started the project came from an enterprise Java background, and his code was the stereotypical design pattern pileup. I only jumped in because he was having trouble actually wrapping it up, and, with every commit, I deleted a bunch of code and replaced it with just a small fraction of what was there before, and he reviewed the changes and agreed they were an improvement. Yet, even though he genuinely agreed his code was overly complicated, he never internalized the learnings, and kept repeating the same mistakes over and over again. He was fixated on the idea that his coded needed to be extensible (without a clear notion of how or why) and kept adding abstraction after abstraction for every new feature he added. So, yes. It is uncontestably true that you often need to write 4k LOC before you understand how to write the same thing in 2k LOC. But it's also very much the case that there's a baseline of skill you need to write those 4k LOC instead of a 10k monstrosity.

hprotagonist 4y ago

My favorite PRs of late have come in at numbers like +280/-1257. (I replaced a lot of janky flask handholding with the equivalent fastapi machinery, to much joy.)

gcanyon 4y ago

I like this one almost as much as "And then he discovered loops!" https://www.folklore.org/StoryView.py?project=Macintosh&story=Discovered_Loops.txt https://www.folklore.org/StoryView.py?project=Macintosh&stor... I use the loops one more often in discussing development.

Wowfunhappy 4y ago

Allow me to play devil's advocate for a moment: Most good writers will tell you that shorter is almost always better. You want to express your thoughts in the most succinct way possible. Review your own writing to remove as much as you can, then hand your draft off to an editor who'll try to cut even more. And yet, many writers are still paid by the word, and many book contracts still specify target page counts. Because even though shorter is better, the shortest possible length of a given text still serves as a rough measure of that text's breath and complexity. Is code any different? Yes, paying or evaluating programmers by lines of code is going to lead to misaligned incentives. However, I'm not convinced the dynamic is any worse than for prose. Bill Atkinson spent a week removing extraneous code from QuickDraw; an author might spend a week cutting extraneous subplots from a novel. Word count is still a useful metric for the author. Perhaps the difference is that non-writers tend to be more familiar with the writing process than non-programmers are with coding. If an author was working on revising a novel, no one would ask them how many words they'd written that week. Or maybe word count measurements are in fact making everyone's prose worse and we should do away with them too.

BlargMcLarg 4y ago
The code is different in the sense that good abstractions and function definitions, when not used in excess, will severely cut down the amount of lines. However, given the same amount of time and not a lot of time spent on thinking about abstractions, odds are they will end up with fairly similar LoC counts. Just developer A will have written more features, whereas developer B will have done the same thing over and over, without having the same features. That's where your example of writers should take hold too: good writers stop being paid by the word and start being paid by number of sales. The same should be done with devs. That said, the entire thing gets tossed out of the window when considering significant portions of developers will overthink abstractions, fiercely hold onto overabstractions (which end up bloating LoC), have discussions with each other ad nauseam, slow down code reviews over petty differences, and more.
- skrtskrt 4y ago
  Also if you write an abstraction then your teammates use it, the measurement on either you or your teammates or both is going to be skewed whether you’re going for high or low LoC. If

deleted 4y ago

[deleted]

grensley 4y ago

I would love love love to see a study on the correlation between lines of code (not net, total changes + and -) and co-worker assessment of aptitude for people in the non-inclusive band from Junior to Architect (aka, people who are really expected to write a bulk of the software).

sdeframond 4y ago

I light of recent Twitter events, I wonder what Musk would think of this...

bheadmaster 4y ago
Is there any evidence that Musk is evaluating Twitter employees based on the LoC written? There's been so much fake news regarding Twitter and Musk these days that I honestly can't tell anymore.
- sillysaurusx 4y ago
  I had the same thought. It’s one of those stories that we’d love to believe, just because it’s so incendiary. But the original source seemed to be an unsourced tweet, and it’s not a good idea to believe those. I’d be interested in evidence too.
- sdeframond 4y ago
  > Is there any evidence that Musk is evaluating Twitter employees based on the LoC written? I've seen in the news that Musk asked devs to print their code for review by Tesla engineers. Not that their LoC would be counted strictly speaking. Now is this piece of news even true?

PragmaticPulp 4y ago

No metric can or should be used in isolation to evaluate productivity. LOC is obviously very flawed, but to be completely honest it has been useful as part of a heuristic for figuring out where something has gone wrong in a department (after applying basic heuristics like removing packaged code, vendored stuff, etc.) For example, if engineers are constantly committing and then deleting huge amounts of code (somewhat like this example) then it’s good to dive in and make sure you don’t have some issues creating that situation. This can range from product managers who aren’t validating their requests before engineers start working on them, to interpersonal issues such as unqualified juniors writing large amounts of buggy code and leaving it for senior engineers to fix. These metrics can also be warning signs that something has gone wrong. If an engineer’s number of commits have plummeted and LOC committed has gone way down, it’s a sign that you should ask more deeply how their work is going. I’ve had situations where programmers were being pulled into 20+ hours of meetings each week and being given weird research assignments from random C-level executives that took away all of their coding time. I’ve also had situations where people weren’t getting along with each other in private and DMs, and the first warning sign was that their contributions stalled. So while LOC and commit metrics can absolutely be misinterpreted in the wrong hands (e.g. as a proxy for laying off Twitter employees without trying to understand the context of their work) I’ve actually found them to be helpful as one of several early warning systems that something is going wrong with a team or project. Work with people for a while and it’s not hard to recognize their normal output and when it has stalled for unexpected reasons. Use that as a signal to start a conversation about how they’re doing.

nonethewiser 4y ago
I setup prettier and ran it against our codebase. Guess I'm the CTO now.

choeger 4y ago

But he didn't write -2000 lines of code, did he? He wrote a new algorithm that was 2000 lines shorter than the old one. So, in principle, there was a positive number of lines that could have been reported. Of course, loc is a bad goal for productivity, but it can still be an interesting measure (similar to test coverage): If I count lines of code added, commits, or tickets closed, I cannot compare any two developers. But if I count that metric for the same developer, or the same team, I can certainly spot changes in productivity. (As every metric has its outliers it would probably be. best to combine all of them.) So if I was managing a team and wanted to know if it would be beneficial to optimize test execution times, I could just rent some bigger machines and see what happens. I could also do a similar experiment with organizational aspects like the size and schedule of meetings or the introduction of a dedicated on-call contact for support requests, etc.

SonOfLilit 4y ago
No, you can't. There is barely any correlation between the amount of new lines of code I wrote in a day and how productive I was that day. As a senior technologist who bills his time as a consultant, I can tell you that I (correctly) get paid the most for days where I write 0 lines of code. But also, my most valuable code was code where I spent a week thinking and writing maybe 5 lines of code a day, and my least valuable code was when my output was limited by my typing speed.
- ShredKazoo 4y ago
  Alternative proposal: Count the number of commits devs are making. Since some devs make more frequent commits than others, for each dev review some fraction of their commits at random, and rate how substantial the randomly sampled commits are. Then multiply average commit importance by number of commits to get an overall productivity score. Thoughts? I think the biggest counterargument is that it incentivizes churn like making a commit and then reverting it later.
  - BlargMcLarg 4y ago
    Your ratings are going to be somewhat arbitrary and the moment this comes out, you'll risk Goodhart's Law anyway. Besides, you might as well start counting closed number of issues/tasks/tickets, story points or whatever, and skip the commit count altogether.

msoad 4y ago

I know lines of code as a measure of productivity has been criticized to death here and elsewhere but today I went and did some analysis on past two years of my team members contributions and saw the team members that I know they are productive are modifying code a ton more than others. It can be subtraction of code too but overall more changes correlated with my perception of their contributions. My perception is pretty informed because I'm their manager and I know this team and this code base very well.

johannes1234321 4y ago
Amount of code can be an indicator, however as soon as developers know it is being used as metric it is easy to manipulate.
- AnonCoward42 4y ago
  "When a measure becomes a target, it ceases to be a good measure." (short form of Goodhart's law)
- expazl 4y ago
  No, it's not easy to manipulate. You're thinking in linear terms which isn't what lines of code changed is useful as. You can't use it to distinguish which of 4 different productive programmers is most or least productive. However it's extremely easy to distinguish the non-productive programmer in the group of 5. And it's not easy to fake, because as soon as that developer start merging in a ton of bogus or useless edits to push up their numbers then everyone on the team, including the manager will call them on their bullshit. It's just like shift times for workers in manual labor jobs. You can't tell which of the people who are meeting up 8 hours a day is most productive based on if they where there for 8 hours and 12 minutes or 8 hours and 25 minutes. But you sure as hell can easily see that if someone is showing up 4-5 hours on a nine-to-five job, then something is wrong. And if that person tries to "fake it" but showing up for 8 hours but spends half the time slacking off, but coworkers and managers will call him on the bullshit.
  - BlargMcLarg 4y ago

xyzzy4747 4y ago

Of the several engineers I've managed at my startup, the ones who wrote the most code got the most stuff done. It's a correlation and there are exceptions, but it's generally the case, at least for new software. A project won't complete itself without a lot of code being written or modified. Although I think total number of PRs is possibly more useful as a metric than total LOC (assuming neither are being gamed).

LtWorf 4y ago
I know people who write quickly huge amounts of very poorly thought of code that will be buggy and will have a bunch of completely useless functions, reimplemented functions that already existed within the project and similar stuff. You might be unaware that you are not such a great manager.
startupsfail 4y ago
This is sometimes true for early stage projects. There are exceptions, sometimes you can have an engineer creating a library or a framework without any need. An existing library would have done a better job faster, but that engineer just wanted to make a new one. As a result you can have a massive framework, known only by that engineer in which that engineer is very effective. But no one else is. And overall it is a liability, if compared to an existing framework. In general, the more code you have the more code you have to maintain and massive codebase churned out by a single engineer is more often a liability, not an asset.

slantedview 4y ago

I love that 40 years later, a prominent tech company leader still has yet to learn the lesson of this story.

pjc50 4y ago
People love reasoning things from first principles rather than learning.
- sixstringtheory 4y ago
  Isn’t reasoning things from first principles exactly how you learn? I think what you meant was that people love learning lessons the hard and slow way instead of taking others’ word for it. I’m sort of conflicted on this. Yes, it is faster to take an expert’s word for it. But after a couple of human generations of that, do we actually lose understanding? I think we can only stand on the shoulders of giants standing on the shoulders of giants to some N giants until the whole acrobatic totem pole comes tumbling down. The game of telephone through the ages produces belief, not understanding. Another option is making giants more giant, but that is an even slower process than one person learning from first principles: humanity has to find a way for our brains to learn those principles faster. Maybe that will take millions of years of evolution. Or maybe something like neuralink will provide a shortcut so it only takes thousands of years.
- _dain_ 4y ago
  people also love getting filthy fucking rich, how's that working out for you?

ihateniggas 4y ago

mepiethree 4y ago

There are any number of counter examples to most of these metrics, but I think the extreme counter examples are often in bad faith. You can’t convince me that a JavaScript engineer who consistently authors 1 commit a month is productive. At some point, you need to stop talking about stuff and actually build stuff Of course you can’t determine the best person by lines of code (package.lock files lol) but you can often make a guess at the worst person

lanstin 4y ago
If they mostly are telling other people what to do to make the other people write better code, then yeah, they can be productive to the work of the company. In a good job, I will save more time by tweaking other peoples plans than any direct execution I do. There is a reason the best management is management by walking around, talking to people, finding it what is actually going on.
- dbish 4y ago
  That’s a manager then, not a software engineer/developer role if your whole job is directing others and not doing any coding yourself, and I’d posit that if you are doing that for too long, you probably shouldn’t be tweaking anyone else’s code eventually since you will lose touch with the system if you aren’t coding and your advice shouldn’t be at the program level anymore.
  - lanstin 4y ago
    Not if your job is only to make people better programmers, not responsible for product deliveries but responsible to code quality, code brevity, long term maintainability, that sort of thing. If you keep pairing with people and pointing out better ways of doing things, ways of doing things that they might have considered impossible but have some hackish solution of a category they haven’t used before, or of building things towards your desired long term plans but not specifically asked for by product/customers, the job is only code and coding, but also enculturation of a group into a common vision that can make for very high performing groups of developers.

cathdrlbizzare 4y ago

Dead Code Society ftw

anonymousiam 4y ago

Seems like whenever I write a bunch of code, it's always bigger before I've completed the test/debug phase. I put this down to revisiting all the algorithms while finalizing the code, and making adjustments/optimizations where it makes sense.

ChrisMarshallNY 4y ago
I do a lot of that. Also, when I review the code documentation. I will sometimes, completely rewrite methods.

andirk 4y ago

How about get to know your team and it becomes very obvious who is more productive. If you need a metric for, say, large teams, how about: # PRs x level of effort, + bonus points for being useful outside of code. Great engineers are like a 5'10" [attractiveness redacted] [hair color redacted] [gender redacted]; it's very obvious, isnt it??

jspash 4y ago

The first thing I look at when reviewing a pull request is the total lines of code added and removed. If the number is over a certain amount (it differs depending on the language and task) I will immediately reject it and ask for a one-on-one. Too many additions or deletions are a signal that something went wrong somewhere. Either the dev went off piste or the task wasn't properly specified. Or sometimes an auto-formatter has gone on the fritz and "prettiered" everything up.

mrjin 4y ago

That was almost exactly what happened to me a couple of years ago. The company hired a terrible guy with an architect title. What he did was some really simple 3rd party integration sending some transaction details to an accounting provider. Instead of reading from db, he decided to intercept those before saving to db coz some of those were not saved at all (only a problem for accounting, but most of the customers did not use accounting providers anyway). So, he spent over a year on that and moved on to another project. I took the project over and lots of complaints from beta testing customers. My manager and I spoke to him about it and never get anywhere. "Look, I can spend another year on this, and it might never really work. How about let me scrap his sh*t and start over?" I proposed. Months later, green light I got. So I deleted all his code solely for that part, around 5k lines and replaced with merely ~300 lines, never had an issue since then. Soon we hired a new Product Lead, the first thing he did was asking how many lines code we wrote in the past year. Errr, okay, so I pulled out stats from source control. Ouch, it was minus ~3k lines.

mark_undoio 4y ago

I like to call this "net negative development"! Valuable contributions to an established codebase can involve a tiny amount of code but a massive amount of understanding, so it's easy for a developer to clean up more in old code than they add in new code. There must be a point where this doesn't hold as well - new feature projects or, especially, newer projects themselves - where adding code is more correlated with value.

SergeAx 4y ago

Once on the interview in the part "what do you want to know about the company and our team" candidate asked me what kind of new code my best engineers are adding to the codebase. Almost immediately I answered that the best engineers here are mostly removing code, because it is much harder problem.

ibbtown 4y ago

I'm sure it was a unsigned integer. So probably he made a record :)

aaron695 4y ago

deleted 4y ago

[deleted]

anonu 4y ago

You pay good developers for the lines of code they do not write.

michaelcampbell 4y ago

I've been a developer professionally since the mid 80's, and working for other people since the early 90's, and never once have I ever seen LOC used for anything but code reviews where "lines per function" had an upper limit. Never heard of anyone using it, nor worked with anyone who encountered it as described. Where are these LOC counting managers I hear so much about?