15 ms·

-2000 Lines of Code

646 points by pcr910303 6y ago

neha555 6y ago
RSMSSB Stenographer Admit Card 2021 https://karnatakastateopenuniversity.in/rsmssb-stenographer-admit-card.html https://karnatakastateopenuniversity.in/rsmssb-stenographer-...
khaledh 6y ago
My favorite quote about this topic: Measuring programming progress by lines of code is like measuring aircraft building progress by weight. - Bill Gates My personal point of view is that: every line of code you write is a liability. Code is not an asset; a solved problem is. Edit: To clarify, I'm definitely not encouraging writing "clever" short code. Always strive to write clear code. You write it once, but it will be read (and potentially changed) many, many times.
- Waterluvian 6y ago
  Some take "line of code" literally. Others see it as a stand-in for complexity. Because one can certainly make a short program that's far more of a liability than a long one. I'm wondering if there's a quality term for a "unit of complexity" in code? Like when a single line has 4 or 5 "ideas" in it.
  - segfaultbuserr 6y ago
    There are many metrics for measuring the logic complexity of code. An early and best-known one is Cyclomatic Complexity [0] - The more possible execution paths, the higher the score. You can find more at Software Metric [1]. [0] https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity [1] https://en.wikipedia.org/wiki/Software_metric https://en.wikipedia.org/wiki/Software_metric
    - Waterluvian 6y ago
      Perfect. This is what I was curious about. Haven't heard of either. Thank you.
    - gurkendoktor 6y ago
      If there is a useful metric, then I haven't found it yet. The data on cyclomatic complexity[1] does not convince me, and in practice, the linters I've seen have complained about boring code like this: switch (foo) { case KIND_1: return parseObjectOfKind1(); case KIND_2: return parseObjectOfKind2(); case KIND_3: return parseObjectOfKind3(); ... case KIND_15: return parseObjectOfKind5(); case KIND_16: return parseObjectOfKind16(); } There are 16 paths and yet this code is easy to follow. There is no substitute for human judgement (code reviews). [1] https://en.wikipedia.org/wiki/Cyclomatic_complexity#Correlation_to_number_of_defects https://en.wikipedia.org/wiki/Cyclomatic_complexity#Correlat...
      - Waterluvian 6y ago
        That's what I was thinking about when I used "ideas". To me there's one main idea in all that code: "we are returning a parsed object of a kind" Not that I'm trying to sell "ideas". I don't even know. But it's this very loose concept that floats around my mind when writing code. How many ideas are there in a stanza? Ahh too many. I should break out one of the larger ideas to happen before.
        segfaultbuserr 6y ago
        Speaking of measuring "ideas", the holy grail of complexity metric is Kolmogorov complexity - theoretically, the inherent complexity of a piece of data (including code) can be defined as the shortest possible program that generates it. For example, 20 million digits of pi or a routine that uses 20 branches to return the same object has low Kolmogorov complexity, because it's easy to write a generator for that, meanwhile a parser is more complex. But it's only a mathematical construction and is uncomputable, just like the halting problem. In real life, for some applications a good compression algorithm like LZMA is sufficient to approximate it. But I'm not sure if it's suitable for measuring computer programs - it would still have a strong correlation to the number of lines of code.
  - khaledh 6y ago
    I'm definitely not encouraging writing "clever" short code. Always strive to write clear code. You write it once, but it will be read (and potentially changed) many, many times. As for complexity metrics, this is a contentious topic. It's hard to quantify "ideas" or "concepts". I think this is the part where technical design reviews and good code reviews help keep in check.
  - WorldMaker 6y ago
    Developers have tried to build metrics for "complexity" over the years. Cyclomatic Complexity is often pointed to as one of the more successfully deployed: https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity As with any metric, it's something to take as useful "advice" and becomes a terrible burden if you are optimizing for/against it directly. (Such as if you are incentivized by a manager to play a game of hitting certain metric targets.) It's also interesting to note that a complete and accurate complexity metric for software is likely impossible due to it being an extension/corollary of the Halting Problem.
  - Twirrim 6y ago
    My IDE spits out a warning when I reach a certain level of complexity in a method, using Mccabe's Cyclomatic Complexity as a measure. It roughly maps with "too many if statements" in my case.
- stocknoob 6y ago
  "My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger." -E. Dijkstra
  - jjice 6y ago
    I'd expect nothing less wise from Dijkstra. I feel like every week I learn something new from that man.
  - mumblemumble 6y ago
    I prefer the Gates version. Dijkstra's implicit premise rather naively assumes that it is somehow less expensive to produce fewer lines of code. It's arguably such an absolute statement that it subtly encourages people to engage in undesirable behaviors such as playing code golf at work. Gates's, on the other hand, accurately captures the reality: while, all else being equal, a lighter-weight design is preferable to a heavier one, it takes some skill and effort to actually produce the lighter design. Which leaves open the possibility that doing so may not actually be worth the effort.
  - msla 6y ago
    The relevant metric isn't lines but concepts: Which code does it in the fewest new ideas? Generally, that's the best, where "new ideas" would be ideas new to a domain expert. For example, in a video game, each of the specific monster types is an idea someone who is an expert in that game would know. The ideas in the memory management code are new. You can't remove all code relevant to a specific monster without removing that monster, at which point you're no longer implementing the same game, but slimming down the number of new concepts in the memory management code is not directly relevant to gameplay. In short: Make program logic similar to business logic.
- klingon78 6y ago
  This is great. Another thing is that sometimes leaving things as-is can be better than making changes. The problem you might be avoiding is change. Things that are bad should probably be fixed, though.
- ragnese 6y ago
  I agree. But, like everything, even this concept gets abused. Example: "Zero code solutions". Hell, we even had that back in the old days with Java frameworks doing a ton of configuration via XML files. Sure, it's not "code", but it's basically the same thing and still a liability. Especially if there's a very steep learning curve to all of the features/configurations that you'll never use. A more subtle problem with abusing this idea is the over-dependency on third party code. Sure, it might look like you haven't written any code when you do `npm install foo`, but really, you've just placed a bunch of trust in some other person. Do you vet your dependencies' authors the same way you vet potential employees at your company? There's a fine line and it's an art form figuring out when to bring in outside code or to NIH it. IMO, of course.
  - deleted 6y ago
    [deleted]
  - mikepurvis 6y ago
    I'm hitting this right now with having just inherited maintenance of a complicated CI pipeline with a lot of intermediate containers based on generated Dockerfiles, all of which runs by bind-mounting docker.sock— basically stuff that might have been best practice 3-4 years ago, but for which there are absolutely better solutions now. Anyway, it's interesting evaluating those potential solutions, because certain things like going to a daemonless, rootless, bind-less build based on podman/buildah is a no-brainer, but the next frontier beyond that has a bunch of tools like ocibuilder, cekit, ansible-bender, etc which want to establish various ways of declaratively expressing an image definition, and although the intent is good there, it's absolutely not worth getting sucked into long-term dependence on pre-1.0 tools with single-digit number of contributors and an uncertain maintenance future.
  - richardwhiuk 6y ago
    > Sure, it's not "code" I utterly reject this assertion.
- jaylo2015 6y ago
  Agree. But then the problem becomes how to count solved problems. One equally terrible practice is to count number of tickets solved. I found this is somewhat true in my career: bug fixes == job security. I cannot morally accept this but I have seen this again and again.
- Cd00d 6y ago
  I think it's in the application for DE Shaw that you're asked to number the lines of code you've written in your career in the various languages you claim to have experience in.
  - asdff 6y ago
    I wonder if they then normalize this by years of experience
- AnimalMuppet 6y ago
  > My personal point of view is that: every line of code you write is a liability. Very true... but also false in a way. Here's a little bit of functionality that has to be in there to implement the way we're solving the problem. That code is a liability; it would be better to solve the problem in a way where we don't need this bit of code. But given that we're solving it this way, let's say that this little bit of functionality may be implemented in one line, which is almost unreadable, or in five very clear lines. That one line is far more of a liability than the five lines are.
- rakoo 6y ago
  To be more precise, every line of code is debt. You get immediate benefits (working software) but you need to pay recurring obligations (bugs). Just like debt, there is a right amount to have: too much and you are incapacitated because you owe more than you can produce, too little and you don't have enough runway to produce what you want. Note that I'm talking about from a company's point of view.
- deleted 6y ago
  [deleted]
fredley 6y ago
I am a staunch code minimalist. Less code is (almost?) always better. The best, fastest, cleanest code is the code that doesn't exist at all. Always aim to write the least code. Less code is less maintenance, it's less to grok for the next person to read it.
- sneak 6y ago
  I used to have this approach, but when you start to take deps into account, it is often preferable to have a medium amount of code in your own codebase (that eliminates some bulky deps) to a small, fast, clean/easy to read in full codebase that depends on some large external libraries that bloat the overall size of "lines of code in use in this application". Now I am a dependency minimalist (as much as is practical, it's a continuous gradient trade-off and naturally YMMV) more than I am a pure code-written-here minimalist. I'll happily double my SLOC for most small apps if it means my app can be stdlib only.
  - fredley 6y ago
    Yes, fully agree. The only thing worse than code you have written is code you haven't.
    - folkrav 6y ago
      To a point. Some things are complex enough that relying on a well tested and supported third-party makes way more sense than re-inventing the wheel.
      - colejohnson66 6y ago
        I think a great example of that is GUI toolkits. If your program is supposed to be cross platform, using something like Qt, GTK, wxWidgets, etc. is generally preferred to writing your own GUI code.
        srgpqt 6y ago
sdevonoes 6y ago
Nowadays that should be phrased as: fewer features is better. But management doesn't understand. They always want more features to be delivered (and faster than our competitors!), and so we end up with more code to maintain and in the need of hiring more developers (that's actually another excuse as well to migrate our stuff to microservices!). Companies only want to grow, they don't care anymore about polished products. Of course, I'm generalizing, there are some few companies that care about the product, but they are just a few.
josalhor 6y ago
Just the other day I was in my logistics class and the professor started deviating into something that I believe was pure nonsense. He started the lecture by analyzing how many pieces a machine could manufacture per day. Fair enough. He extended the model to measure different ratios of capacity. Makes sense. Then he tried to extend the model to all machines, including humans. His example was: "How do you measure the capacity of a legal team?". I thought it was a trick question, so I answered (paraphrasing) "You can't answer that question the same way you answer for the machine. You can't give a single metric." He told me I was wrong and that the _right_ measure would be (total number of working hours/day). I was tempted to try to convince him otherwise. The analogy was deeply flawed. He certainly measured the machines in (number of pieces / day) but measured the legal team in (hours/day). So, in analyzing a machine, you take into account its efficiency, but you don't do the same thing for humans. I believe that is exactly the same thing that is going on in the post. Managers/Logistics/Economists are very susceptible to this kind of generalization pitfalls. Edit: Given that this answer has generated some discussion I feel the need to expand on it. The legal team was not expected to sell their services "by the hour". In fact, any discussion about how their services were sold was shut down by the professor. From his point of view, the lawyers were machines and he was asking the question "how much can this machine produce?" Yes, other students also suggested taking the number of billable hours/revenue into account, but that's not the answer the professor was looking for. I don't criticize whether his answer is not technically right, but I feel it holds no real-world meaning. It was a purely academic question that leads nowhere instead of having a debate about how you measure the productivity of a group of human beings. And on top of that, his final answer was definitive and (from his point of view) was irrefutable.
- rkagerer 6y ago
  Wow. Even with such a basic analogy, there are still more useful metrics you could pick... contracts closed, cases won, client files completed, cigars smoked.
- rebuilder 6y ago
  Well, lawyers are famously expensive. And time is money. So presumably a sufficiently expensive legal team will actually produce hours, and the measurement is perfectly reasonable.
dhosek 6y ago
I track my progress on the novel I'm writing by word count. I've had more than a few days of negative word count writing days which have invariably been some of my more productive days.
hinkley 6y ago
Sometimes I wish I kept a better count of my deletions, because the 'best' I ever recorded was just under 600 lines and I honestly feel a little regret that other people are managing much bigger deletions. I think the real reason is that as I moved to refactoring (as part of that 600 LOC experience), my deletions per year went up but my deletions per story regressed toward the mean.
- closeparen 6y ago
  There are various ways to extract this from Git, see for example: https://shinglyu.com/web/2018/12/25/counting-your-contribution-to-a-git-repository.html https://shinglyu.com/web/2018/12/25/counting-your-contributi...
mshockwave 6y ago
It's crazy that even in 2021, I know some of the teams are still measuring productivity by LOC _only_. People just never learn the lesson since '80
- segfaultbuserr 6y ago
  > Measuring programming progress by lines of code is like measuring aircraft building progress by weight. - Bill Gates (alleged) According to Wikiquote there is no primary source to show he really said that. Nevertheless, Steve Ballmer did, > "In IBM there's a religion in software that says you have to count K-LOCs, and a K-LOC is a thousand line of code. How big a project is it? Oh, it's sort of a 10K-LOC project. This is a 20K-LOCer. And this is 5OK-LOCs. And IBM wanted to sort of make it the religion about how we got paid. How much money we made off OS 2, how much they did. How many K-LOCs did you do? And we kept trying to convince them - hey, if we have - a developer's got a good idea and he can get something done in 4K-LOCs instead of 20K-LOCs, should we make less money? Because he's made something smaller and faster, less KLOC. K-LOCs, K-LOCs, that's the methodology. Ugh anyway, that always makes my back just crinkle up at the thought of the whole thing." Not really a fan of either of them, but we can all agree on the quote.
- adolph 6y ago
  Ssh, this may be a feature, not a bug. See CIA (OSS) manual for details. https://www.openculture.com/2015/12/simple-sabotage-field-manual.html https://www.openculture.com/2015/12/simple-sabotage-field-ma...
- asdff 6y ago
  Must be great for those teams. Want to make an argument for a raise to non-tech management? Start writing paragraph comments and flowery code.
- newlisper 6y ago
  Use Java, problem solved.
- goostavos 6y ago
  I'd be happy if lessons from the '60s-'70s(ish?) could be applied. Despite Mythical Man Month being 'required reading', I still sit in planning meetings where management discusses how they'll make a baby in 1 month because they're putting 9 "resources" on it.
cbsks 6y ago
One of my most proud accomplishments was reducing the size of a driver from ~3000 lines of code to ~800. The file was 15 years old and had been modified by many people since. There were conditionals that were impossible to hit, features that had been abandoned years ago, duplicate code, and lots of comments that didn’t match the code anymore. After my changes and a few new tests, the driver had full MCDC code coverage and the code actually matched the device specification!
- apozem 6y ago
  That's awesome. Clearing out cruft without breaking anything or losing functionality is tricky, but man does it feel good.
- JoeAltmaier 6y ago
  That is a win for everybody! My similar story was removing a 10,000 line module that built hundreds of different packets for sending over a mailbox to a wifi module. Each method was almost identical, with the exception of building a slightly different header. I replaced it with a template that given the structure, built a packet to send it. Less than 1 page of code.
  - bostonvaulter2 6y ago
    Wow, that almost makes it sound like the original author was getting paid per line.
    - JoeAltmaier 6y ago
      Must have. It was a new version of an old driver. The old driver was 9 modules. The new one - 900. Every tiny little thing was another module. It conversed in 802.11 and ethernet etc, so of course it had three (3) copies of non-compatible packet layout declarations, each comprising dozens of modules. And on and on. It was like a computer science geek gone mad had figured, "I'll use every decomposition technique I ever heard of, and invent some more, so this is the most computer-sciencey source base in the world". Ultimately I rewrote it in 12 C++ base classes and a derived object for each radio card I had to work with.
Waterluvian 6y ago
Folklore.org is full of fascinating anecdotes. I'm starving for more stories of this size from CS history. PARC, Bell Labs, wherever! I'm sure there's thousands of fun little stories out there.
- feydaykyn 6y ago
  Here are two great books on the topic: - xerox dealer of lightning, about PARC: https://archive.org/details/dealersoflightni00hilt https://archive.org/details/dealersoflightni00hilt - fire in the valley, about the development of personal computers : https://www.goodreads.com/book/show/1427580.Fire_in_the_Valley https://www.goodreads.com/book/show/1427580.Fire_in_the_Vall... My personal favorite is The soul of a new machine, an account of a team trying to create a new computer : https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine
meepmorp 6y ago
There are some fascinating stories on the site, including some ones about Bill Atkinson (the programmer here) that really help to flesh out the sheer absurdity of asking him, in particular, to fill out a sheet like that. I believe he personally wrote something like 2/3 of the original Macintosh ROM. edit: here's one that I find to be an interesting character study: https://www.folklore.org/StoryView.py?story=Round_Rects_Are_Everywhere.txt https://www.folklore.org/StoryView.py?story=Round_Rects_Are_...
protomyth 6y ago
Say what you want about Steve Balmer but he had the right attitude towards that https://www.youtube.com/watch?v=kHI7RTKhlz0 https://www.youtube.com/watch?v=kHI7RTKhlz0
JoeAltmaier 6y ago
Consider the cost of lines of code in a solution. Double the lines means double the time spent to simply type them in. Double the time later to read them. Probably many more times than double to re-understand them. Double the time to explain them. Double the compile time. Execution time is probably around double. It's not just twice as good to write shorter code. Its something like 64X as good. By some ways of thinking.
- Jtsummers 6y ago
  It's definitely a compounding issue as you grow and shrink SLOC. One bit of code I received was somewhere in the range of 5-10k SLOC when handed to me. I reduced it to around 1k SLOC. The original included numerous duplications, had a function that was itself on the order of 1-2k SLOC, was miserable to extend (which path do I need to follow to insert this new conditional? which paths will be impacted if I remove this conditionals?). Fortunately it wasn't shipped code, but it was useful for testing the embedded system. My refactoring involved, first, re-coding one of the larger, outer if-else-if sequences as a simple switch/case. This quickly revealed which variables were common to a large number of the branches and could be brought to a higher level of scope. Then common series of statements were parameterized and extracted to functions (preambles and postambles, setup and teardown, if you will). Several hundred lines were replaced with something like one 20-line function which took a single parameter and one call to it with the parameter that was previously evaluated through some hairy if-else-if sequence. Once completed, new test sequences could easily be coded up or were available because there was already a path that led to it, you just had to feed it a different value or series of values to trigger that path. Then we could automate the whole thing because we knew what the parameters were that clearly led to each branch. In the end the code was 5-10x smaller, but immensely more valuable.
everybodyknows 6y ago
The management psychology side of this wants a sequel from some veteran who was in the meetings and is now ready to confess: > ... wrote in the number: -2000. > I'm not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied. Bill — but what about the rest of the team? The devil’s answer: They were expected to keep supplying the number, because line management was forwarding the stats up, having previously “sold” upper management on their value. And to admit error on such a fundamental is career-threatening.
Zelphyr 6y ago
I had a manager once tell a co-worker (who is easily one of the best programmers I have ever worked with), "There's no way this can work. There's not enough code." Why we keep promoting these people into positions of management is beyond me.
mynameisash 6y ago
"It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove." - Antoine de Saint Exupéry
noarchy 6y ago
There are still companies trying to impose metrics on software development. It isn't just lines of code, it may also include commits per day. And this isn't even taking into account various "Agile"-related metrics, like story points per sprint and the like. I wonder if we should name the companies who do this, or if it is fighting a losing battle? In the end, some management just wants to look at charts.
- Zelphyr 6y ago
  One of the greats is "number of bugs fixed". You're practically begging your less-than-ethical programmers to create silly bugs so they can "fix" them and get a cookie. Edit to add: This happens outside of programming as well. I know a guy who worked at AT&T as a DSL Installation & Repair tech. They had such a focus on how long techs spent on a given job (less time was encouraged, more time was penalized) that a lot of his co-workers would go to the DSLAM and snip a wire so that they would be called out the next day to fix the problem. He pushed back so heavily on the poor incentive of "getting your numbers up" that he eventually got written up for insubordination. We need a larger eye-roll emoji.
  - quercusa 6y ago
    There's a old Dilbert to that effect. Wally: "I'm going to write myself a minivan!"
  - Jtsummers 6y ago
    Of questionable ethics, at one office there was no reward for finishing a large number of tasks. But there was an implicit penalty for delays and the tasks were not properly segregated by effort. One of the testers had something like 300-400 test cases he was automating. The majority were simple, minutes to an hour of work, and easily sharing common code. 50 or so were large, taking several days or even a couple weeks of effort. Even though he, technically, could have finished the majority of test cases in a couple weeks, he knew that they'd expect that pace to continue. Consequently, he left all those small cases for later. It was simpler this way than fighting the misperception that all the work was of similar effort. If he ever seemed to be falling behind, he'd churn out 20+ test cases on Friday and the reports for the week looked good to management. I've never done this myself, but I've seen developers do similar things rather than fight management. Measuring and rewarding the right things is important.
carapace 6y ago
> My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. ~Dijkstra (1988) "On the cruelty of really teaching computing science (EWD1036). https://en.wikiquote.org/wiki/Edsger_W._Dijkstra https://en.wikiquote.org/wiki/Edsger_W._Dijkstra
lambda_obrien 6y ago
Is there anywhere which optimizes for LOC count today? I figure everyone knows by now LOC is a bad metric.
ChrisMarshallNY 6y ago
The best code is the code I don't write. As a manager, I would value a developer that spent a week, refining a small, high-quality, robust and performant class, than one that churned out rococo monsters in a short period of time. I tend to write a lot of code, and one of the things that I do, when I refactor, is look for chunks I can consolidate or remove. OO is a good way to do that. It's a shame it's so "out of fashion," these days. The ability to reduce ten classes into ten little declarations of five lines each, because I was able to factor out the 300 lines of common functionality, is a nice feeling. An interesting metric for me, is when I run cloc on my codebase. I tend to have about a 50/50 LoC (Lines of Code) vs. LoC (Lines of Comments).
Havoc 6y ago
You can tell it’s folklore by the part where they stop making him fill out the form 3/10 for realism
mangomania 6y ago
Good job!
dang 6y ago
If curious, past threads: -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)
- jansan 6y ago
  Was there really a 5+ year gap since the last thread? We should not let this happen again.
  - dang 6y ago
    Perhaps someone will find other cases of this story showing up.
  - utopcell 6y ago
    (-:
  - taneq 6y ago
    So you’re saying the last thread was -2000 days from now?
    - pizza 6y ago
      1911 days ago.. so, yeah, within 5% accuracy!
  - gus_massa 6y ago
    There are many more, but dang only posted the ones that got traction https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=2000%20%22Lines%20of%20Code%22&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... (last one was 20 days ago, 1 point, 0 comments)
methyl 6y ago
If you want to read about flawed metrics, how they affect the production and what to do about it in a form of interesting novel - check out The Goal by Elijjahu M. Goldratt. It's a classic, but gets recommended seldom for how good it is.
csours 6y ago
Disclaimer: I work for GM - this is solely my own opinion. Whenever I hear people in the automotive industry boast about the complexity and lines of code in vehicles I weep and shake my head.
- Jtsummers 6y ago
  It happens in aerospace as well. I had a manager boasting, once, about the skill of his people and the product with something like, "This was 100k lines of code!". In working with some of those people (a couple specific individuals) later I realized that the 100k lines of code was probably reducible to 10-20k lines of code if it was anything like their later work. The code they wrote worked, but was not extendable or comprehensible by anyone but them, and I spent more time refactoring and shrinking their work than actually extending it.
- Yeroc 6y ago
  I heard Elon Musk state in an interview that they gave every new line of code 1 point and every deleted line of code 2 points so clearly at least Tesla seems to value fewer lines of code. Reference: https://youtu.be/YAtLTLiqNwg?t=953 https://youtu.be/YAtLTLiqNwg?t=953
jansan 6y ago
Aaah, now I understand how people came up with the strange idea to place opening curly brackets into a new line. Suddenly this all makes sense.
beaconstudios 6y ago
This take is probably going to be controversial here, but I suspect that most metrics don't accomplish anything beyond giving control freak managers a sense of control or insight. Most complex processes can't be reduced to a handful of simple variables - it's oversimplification at its worst. The best you can do is use metrics for a jumping-off point for where something /might/ be going wrong and thus start engaging with actual humans (or reading code/logs/some other source of feedback). Too often I've had to deal with management who go straight from metrics to decisions and end up making bad decisions (or wasting everyone's time shuffling paper to generate good looking metrics).
- andrewflnr 6y ago
  > This take is probably going to be controversial here, but... You then state what seems to be the mainstream view on HN. Certainly I don't see it as controversial, just kind of obvious
  - beaconstudios 6y ago
    I figure it to be controversial because I see the HN crowd as leaning more towards maths/reductionism/measuring than intuition/holism/feedback and while I'm specifically levying the anti-quantification argument against managers in this case it also applies to that approach in general.
    - andrewflnr 6y ago
      Yeah, but OTOH we're mostly software people who have seen first-hand what happens when you try to apply naive metrics to software. In other fields you're more likely to be right.
    - SamBam 6y ago
      A large percent of HN are software developers, and no developer wants to be held to some metric by some non-developer boss.
- bawolff 6y ago
tregoning 6y ago
Related :) https://twitter.com/tregoning/status/1286329086176976896 https://twitter.com/tregoning/status/1286329086176976896
Twirrim 6y ago
Years ago I worked for an ISP & managed hosting company as third line support. 1st and 2nd line support were pretty good, and would handle a lot of the cases that came through. Generally by the time it'd reach us, it was something requiring more in depth troubleshooting. They introduced a metric to measure ticket performance. The rough idea was "faster it's resolved, the better" (reasonable measure, if you're also tracking customer satisfaction), combined with "fewer interactions with customer the better" which was an absolutely stupid way to measure performance. About a month after it came out, we were getting chewed out for our "conversion score" being low. Too many interactions with customers, and tickets taking a while to handle. No shit, we're the top tier of support. If it got to us it was bound to take time to resolve, and almost certainly involved a lot of customer interaction. One of the engineers in the team managed to dig up how to get a "conversion" rate report up for any support engineer, though not the code that generated the figures, and very quickly realised that the way to get 100% conversion rate was just to resolve and immediately re-open the ticket as soon as you picked it up. We all promptly started doing that, and they stopped chewing us out. If you incentivise the wrong behaviour, you're going to get results you likely don't want.
- suhlig 6y ago
  „When a measure becomes a target, it ceases to be a good measure.“ https://en.wikipedia.org/wiki/Goodhart's_law?wprov=sfti1 https://en.wikipedia.org/wiki/Goodhart's_law?wprov=sfti1
sanj 6y ago
I once removed 4 lines of code. The change, annualized, was somewhere around $12M in profit. I'm still pretty proud of making -$3M/LOC!
einpoklum 6y ago
More than the story itself, the website: https://www.folklore.org/ https://www.folklore.org/ is packed with stories which will make you smile, cry, or more enlightened. Or all of the above at the same time.
TheDudeMan 6y ago
> they stopped asking Bill to fill out the form, and he gladly complied. Compiled with what? Can one comply with an absence of request?
Scarblac 6y ago
Those few days that I managed -1000 lines of real code are among the happiest work-related days I had. It feels so good to find a simple solution that enables you to remove so much.
blunte 6y ago
One of my tasks as a young developer was to make a shell script faster. The systems engineers (who used this script to setup and configure large scale network management systems) were complaining that the "menu" took 60 seconds or more between selections. Ok, sure, sounds easy. Then I opened the script... 9000 lines. After reading and understanding what it was supposed to do, I rewrote it in 1500 lines (still basic SunOS unix shell code), and with reasonable use of internal data structures for caching so only the first menu visit required a time hit. Beyond that, it was 1 second for menu selections. To say the system engineers were pleased would be an understatement. My manager was pleased but also displeased, because he was the author of the 9000 line monstrosity.
deleted 6y ago
[deleted]
h0mie 6y ago
jkj
chrisweekly 6y ago
In general, code is a liability, not an asset.
sswam 6y ago
We could measure lines of code added, multiplied by quality of code as determined by some coding standards or occasional peer review, and credit for removing inferior code. I guess it needs thought. I've noticed, as a programmer myself, that my quantum nature does not enjoy being measured in this way.
TimedToasts 6y ago
Around the turn of the Willennium, I beat a long-standing "Most C LOC approved in a month" record at Old School Big Name Inc. and you are not taking it away from me. No one had come close to that record in a decade and I beat it and you can kiss my keyboard if you think I was lazy about it. Harumph, I say!
bdg 6y ago
Is it just me or does the average engineer in most companies produce something like 150 lines of code per day when averaged over a year?
bjoli 6y ago
I have had code I wrote replaced by something that was 30% smaller, faster and more stable. It was a good and humbling experience. I contributed an inliner to a language about ten years ago. Inlining is a problem that might seem easy at first, but for me it was like trying to restrain a rabid dog on a leash. I was pretty damn pleased with the end results and it served the language implentation well until about 2015. Then someone with an actual understanding of the problem worked on it for a week and produced something that I would describe as poetry.
crsr 6y ago
Bill Atkinson reminds me of Gilfoyle from Silicon Valley
ne38 6y ago
we must measure edited lines not the difference between numbers of lines after and numbers of lines before! It is like if you work in money exchanges: there is buying and selling.
deleted 6y ago
[deleted]

-2000 Lines of Code

646 points by pcr910303 6y ago

RSMSSB Stenographer Admit Card 2021 https://karnatakastateopenuniversity.in/rsmssb-stenographer-admit-card.html https://karnatakastateopenuniversity.in/rsmssb-stenographer-...

khaledh 6y ago

My favorite quote about this topic: Measuring programming progress by lines of code is like measuring aircraft building progress by weight. - Bill Gates My personal point of view is that: every line of code you write is a liability. Code is not an asset; a solved problem is. Edit: To clarify, I'm definitely not encouraging writing "clever" short code. Always strive to write clear code. You write it once, but it will be read (and potentially changed) many, many times.

Waterluvian 6y ago
Some take "line of code" literally. Others see it as a stand-in for complexity. Because one can certainly make a short program that's far more of a liability than a long one. I'm wondering if there's a quality term for a "unit of complexity" in code? Like when a single line has 4 or 5 "ideas" in it.
- segfaultbuserr 6y ago
  There are many metrics for measuring the logic complexity of code. An early and best-known one is Cyclomatic Complexity [0] - The more possible execution paths, the higher the score. You can find more at Software Metric [1]. [0] https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity [1] https://en.wikipedia.org/wiki/Software_metric https://en.wikipedia.org/wiki/Software_metric
  - Waterluvian 6y ago
    Perfect. This is what I was curious about. Haven't heard of either. Thank you.
  - gurkendoktor 6y ago
    If there is a useful metric, then I haven't found it yet. The data on cyclomatic complexity[1] does not convince me, and in practice, the linters I've seen have complained about boring code like this: switch (foo) { case KIND_1: return parseObjectOfKind1(); case KIND_2: return parseObjectOfKind2(); case KIND_3: return parseObjectOfKind3(); ... case KIND_15: return parseObjectOfKind5(); case KIND_16: return parseObjectOfKind16(); } There are 16 paths and yet this code is easy to follow. There is no substitute for human judgement (code reviews). [1] https://en.wikipedia.org/wiki/Cyclomatic_complexity#Correlation_to_number_of_defects https://en.wikipedia.org/wiki/Cyclomatic_complexity#Correlat...
    - Waterluvian 6y ago
      That's what I was thinking about when I used "ideas". To me there's one main idea in all that code: "we are returning a parsed object of a kind" Not that I'm trying to sell "ideas". I don't even know. But it's this very loose concept that floats around my mind when writing code. How many ideas are there in a stanza? Ahh too many. I should break out one of the larger ideas to happen before.
      - segfaultbuserr 6y ago
        Speaking of measuring "ideas", the holy grail of complexity metric is Kolmogorov complexity - theoretically, the inherent complexity of a piece of data (including code) can be defined as the shortest possible program that generates it. For example, 20 million digits of pi or a routine that uses 20 branches to return the same object has low Kolmogorov complexity, because it's easy to write a generator for that, meanwhile a parser is more complex. But it's only a mathematical construction and is uncomputable, just like the halting problem. In real life, for some applications a good compression algorithm like LZMA is sufficient to approximate it. But I'm not sure if it's suitable for measuring computer programs - it would still have a strong correlation to the number of lines of code.
- khaledh 6y ago
  I'm definitely not encouraging writing "clever" short code. Always strive to write clear code. You write it once, but it will be read (and potentially changed) many, many times. As for complexity metrics, this is a contentious topic. It's hard to quantify "ideas" or "concepts". I think this is the part where technical design reviews and good code reviews help keep in check.
- WorldMaker 6y ago
  Developers have tried to build metrics for "complexity" over the years. Cyclomatic Complexity is often pointed to as one of the more successfully deployed: https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity As with any metric, it's something to take as useful "advice" and becomes a terrible burden if you are optimizing for/against it directly. (Such as if you are incentivized by a manager to play a game of hitting certain metric targets.) It's also interesting to note that a complete and accurate complexity metric for software is likely impossible due to it being an extension/corollary of the Halting Problem.
- Twirrim 6y ago
  My IDE spits out a warning when I reach a certain level of complexity in a method, using Mccabe's Cyclomatic Complexity as a measure. It roughly maps with "too many if statements" in my case.
stocknoob 6y ago
"My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger." -E. Dijkstra
- jjice 6y ago
  I'd expect nothing less wise from Dijkstra. I feel like every week I learn something new from that man.
- mumblemumble 6y ago
  I prefer the Gates version. Dijkstra's implicit premise rather naively assumes that it is somehow less expensive to produce fewer lines of code. It's arguably such an absolute statement that it subtly encourages people to engage in undesirable behaviors such as playing code golf at work. Gates's, on the other hand, accurately captures the reality: while, all else being equal, a lighter-weight design is preferable to a heavier one, it takes some skill and effort to actually produce the lighter design. Which leaves open the possibility that doing so may not actually be worth the effort.
- msla 6y ago
  The relevant metric isn't lines but concepts: Which code does it in the fewest new ideas? Generally, that's the best, where "new ideas" would be ideas new to a domain expert. For example, in a video game, each of the specific monster types is an idea someone who is an expert in that game would know. The ideas in the memory management code are new. You can't remove all code relevant to a specific monster without removing that monster, at which point you're no longer implementing the same game, but slimming down the number of new concepts in the memory management code is not directly relevant to gameplay. In short: Make program logic similar to business logic.
klingon78 6y ago
This is great. Another thing is that sometimes leaving things as-is can be better than making changes. The problem you might be avoiding is change. Things that are bad should probably be fixed, though.
ragnese 6y ago
I agree. But, like everything, even this concept gets abused. Example: "Zero code solutions". Hell, we even had that back in the old days with Java frameworks doing a ton of configuration via XML files. Sure, it's not "code", but it's basically the same thing and still a liability. Especially if there's a very steep learning curve to all of the features/configurations that you'll never use. A more subtle problem with abusing this idea is the over-dependency on third party code. Sure, it might look like you haven't written any code when you do `npm install foo`, but really, you've just placed a bunch of trust in some other person. Do you vet your dependencies' authors the same way you vet potential employees at your company? There's a fine line and it's an art form figuring out when to bring in outside code or to NIH it. IMO, of course.
- deleted 6y ago
  [deleted]
- mikepurvis 6y ago
  I'm hitting this right now with having just inherited maintenance of a complicated CI pipeline with a lot of intermediate containers based on generated Dockerfiles, all of which runs by bind-mounting docker.sock— basically stuff that might have been best practice 3-4 years ago, but for which there are absolutely better solutions now. Anyway, it's interesting evaluating those potential solutions, because certain things like going to a daemonless, rootless, bind-less build based on podman/buildah is a no-brainer, but the next frontier beyond that has a bunch of tools like ocibuilder, cekit, ansible-bender, etc which want to establish various ways of declaratively expressing an image definition, and although the intent is good there, it's absolutely not worth getting sucked into long-term dependence on pre-1.0 tools with single-digit number of contributors and an uncertain maintenance future.
- richardwhiuk 6y ago
  > Sure, it's not "code" I utterly reject this assertion.
jaylo2015 6y ago
Agree. But then the problem becomes how to count solved problems. One equally terrible practice is to count number of tickets solved. I found this is somewhat true in my career: bug fixes == job security. I cannot morally accept this but I have seen this again and again.
Cd00d 6y ago
I think it's in the application for DE Shaw that you're asked to number the lines of code you've written in your career in the various languages you claim to have experience in.
- asdff 6y ago
  I wonder if they then normalize this by years of experience
AnimalMuppet 6y ago
> My personal point of view is that: every line of code you write is a liability. Very true... but also false in a way. Here's a little bit of functionality that has to be in there to implement the way we're solving the problem. That code is a liability; it would be better to solve the problem in a way where we don't need this bit of code. But given that we're solving it this way, let's say that this little bit of functionality may be implemented in one line, which is almost unreadable, or in five very clear lines. That one line is far more of a liability than the five lines are.
rakoo 6y ago
To be more precise, every line of code is debt. You get immediate benefits (working software) but you need to pay recurring obligations (bugs). Just like debt, there is a right amount to have: too much and you are incapacitated because you owe more than you can produce, too little and you don't have enough runway to produce what you want. Note that I'm talking about from a company's point of view.
deleted 6y ago
[deleted]

fredley 6y ago

I am a staunch code minimalist. Less code is (almost?) always better. The best, fastest, cleanest code is the code that doesn't exist at all. Always aim to write the least code. Less code is less maintenance, it's less to grok for the next person to read it.

sneak 6y ago
I used to have this approach, but when you start to take deps into account, it is often preferable to have a medium amount of code in your own codebase (that eliminates some bulky deps) to a small, fast, clean/easy to read in full codebase that depends on some large external libraries that bloat the overall size of "lines of code in use in this application". Now I am a dependency minimalist (as much as is practical, it's a continuous gradient trade-off and naturally YMMV) more than I am a pure code-written-here minimalist. I'll happily double my SLOC for most small apps if it means my app can be stdlib only.
- fredley 6y ago
  Yes, fully agree. The only thing worse than code you have written is code you haven't.
  - folkrav 6y ago
    To a point. Some things are complex enough that relying on a well tested and supported third-party makes way more sense than re-inventing the wheel.
    - colejohnson66 6y ago
      I think a great example of that is GUI toolkits. If your program is supposed to be cross platform, using something like Qt, GTK, wxWidgets, etc. is generally preferred to writing your own GUI code.
      - srgpqt 6y ago

sdevonoes 6y ago

Nowadays that should be phrased as: fewer features is better. But management doesn't understand. They always want more features to be delivered (and faster than our competitors!), and so we end up with more code to maintain and in the need of hiring more developers (that's actually another excuse as well to migrate our stuff to microservices!). Companies only want to grow, they don't care anymore about polished products. Of course, I'm generalizing, there are some few companies that care about the product, but they are just a few.

josalhor 6y ago

Just the other day I was in my logistics class and the professor started deviating into something that I believe was pure nonsense. He started the lecture by analyzing how many pieces a machine could manufacture per day. Fair enough. He extended the model to measure different ratios of capacity. Makes sense. Then he tried to extend the model to all machines, including humans. His example was: "How do you measure the capacity of a legal team?". I thought it was a trick question, so I answered (paraphrasing) "You can't answer that question the same way you answer for the machine. You can't give a single metric." He told me I was wrong and that the _right_ measure would be (total number of working hours/day). I was tempted to try to convince him otherwise. The analogy was deeply flawed. He certainly measured the machines in (number of pieces / day) but measured the legal team in (hours/day). So, in analyzing a machine, you take into account its efficiency, but you don't do the same thing for humans. I believe that is exactly the same thing that is going on in the post. Managers/Logistics/Economists are very susceptible to this kind of generalization pitfalls. Edit: Given that this answer has generated some discussion I feel the need to expand on it. The legal team was not expected to sell their services "by the hour". In fact, any discussion about how their services were sold was shut down by the professor. From his point of view, the lawyers were machines and he was asking the question "how much can this machine produce?" Yes, other students also suggested taking the number of billable hours/revenue into account, but that's not the answer the professor was looking for. I don't criticize whether his answer is not technically right, but I feel it holds no real-world meaning. It was a purely academic question that leads nowhere instead of having a debate about how you measure the productivity of a group of human beings. And on top of that, his final answer was definitive and (from his point of view) was irrefutable.

rkagerer 6y ago
Wow. Even with such a basic analogy, there are still more useful metrics you could pick... contracts closed, cases won, client files completed, cigars smoked.
rebuilder 6y ago
Well, lawyers are famously expensive. And time is money. So presumably a sufficiently expensive legal team will actually produce hours, and the measurement is perfectly reasonable.

dhosek 6y ago

I track my progress on the novel I'm writing by word count. I've had more than a few days of negative word count writing days which have invariably been some of my more productive days.

hinkley 6y ago

Sometimes I wish I kept a better count of my deletions, because the 'best' I ever recorded was just under 600 lines and I honestly feel a little regret that other people are managing much bigger deletions. I think the real reason is that as I moved to refactoring (as part of that 600 LOC experience), my deletions per year went up but my deletions per story regressed toward the mean.

closeparen 6y ago
There are various ways to extract this from Git, see for example: https://shinglyu.com/web/2018/12/25/counting-your-contribution-to-a-git-repository.html https://shinglyu.com/web/2018/12/25/counting-your-contributi...

mshockwave 6y ago

It's crazy that even in 2021, I know some of the teams are still measuring productivity by LOC _only_. People just never learn the lesson since '80

segfaultbuserr 6y ago
> Measuring programming progress by lines of code is like measuring aircraft building progress by weight. - Bill Gates (alleged) According to Wikiquote there is no primary source to show he really said that. Nevertheless, Steve Ballmer did, > "In IBM there's a religion in software that says you have to count K-LOCs, and a K-LOC is a thousand line of code. How big a project is it? Oh, it's sort of a 10K-LOC project. This is a 20K-LOCer. And this is 5OK-LOCs. And IBM wanted to sort of make it the religion about how we got paid. How much money we made off OS 2, how much they did. How many K-LOCs did you do? And we kept trying to convince them - hey, if we have - a developer's got a good idea and he can get something done in 4K-LOCs instead of 20K-LOCs, should we make less money? Because he's made something smaller and faster, less KLOC. K-LOCs, K-LOCs, that's the methodology. Ugh anyway, that always makes my back just crinkle up at the thought of the whole thing." Not really a fan of either of them, but we can all agree on the quote.
adolph 6y ago
Ssh, this may be a feature, not a bug. See CIA (OSS) manual for details. https://www.openculture.com/2015/12/simple-sabotage-field-manual.html https://www.openculture.com/2015/12/simple-sabotage-field-ma...
asdff 6y ago
Must be great for those teams. Want to make an argument for a raise to non-tech management? Start writing paragraph comments and flowery code.
newlisper 6y ago
Use Java, problem solved.
goostavos 6y ago
I'd be happy if lessons from the '60s-'70s(ish?) could be applied. Despite Mythical Man Month being 'required reading', I still sit in planning meetings where management discusses how they'll make a baby in 1 month because they're putting 9 "resources" on it.

cbsks 6y ago

One of my most proud accomplishments was reducing the size of a driver from ~3000 lines of code to ~800. The file was 15 years old and had been modified by many people since. There were conditionals that were impossible to hit, features that had been abandoned years ago, duplicate code, and lots of comments that didn’t match the code anymore. After my changes and a few new tests, the driver had full MCDC code coverage and the code actually matched the device specification!

apozem 6y ago
That's awesome. Clearing out cruft without breaking anything or losing functionality is tricky, but man does it feel good.
JoeAltmaier 6y ago
That is a win for everybody! My similar story was removing a 10,000 line module that built hundreds of different packets for sending over a mailbox to a wifi module. Each method was almost identical, with the exception of building a slightly different header. I replaced it with a template that given the structure, built a packet to send it. Less than 1 page of code.
- bostonvaulter2 6y ago
  Wow, that almost makes it sound like the original author was getting paid per line.
  - JoeAltmaier 6y ago
    Must have. It was a new version of an old driver. The old driver was 9 modules. The new one - 900. Every tiny little thing was another module. It conversed in 802.11 and ethernet etc, so of course it had three (3) copies of non-compatible packet layout declarations, each comprising dozens of modules. And on and on. It was like a computer science geek gone mad had figured, "I'll use every decomposition technique I ever heard of, and invent some more, so this is the most computer-sciencey source base in the world". Ultimately I rewrote it in 12 C++ base classes and a derived object for each radio card I had to work with.

Waterluvian 6y ago

Folklore.org is full of fascinating anecdotes. I'm starving for more stories of this size from CS history. PARC, Bell Labs, wherever! I'm sure there's thousands of fun little stories out there.

feydaykyn 6y ago
Here are two great books on the topic: - xerox dealer of lightning, about PARC: https://archive.org/details/dealersoflightni00hilt https://archive.org/details/dealersoflightni00hilt - fire in the valley, about the development of personal computers : https://www.goodreads.com/book/show/1427580.Fire_in_the_Valley https://www.goodreads.com/book/show/1427580.Fire_in_the_Vall... My personal favorite is The soul of a new machine, an account of a team trying to create a new computer : https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine

meepmorp 6y ago

There are some fascinating stories on the site, including some ones about Bill Atkinson (the programmer here) that really help to flesh out the sheer absurdity of asking him, in particular, to fill out a sheet like that. I believe he personally wrote something like 2/3 of the original Macintosh ROM. edit: here's one that I find to be an interesting character study: https://www.folklore.org/StoryView.py?story=Round_Rects_Are_Everywhere.txt https://www.folklore.org/StoryView.py?story=Round_Rects_Are_...

protomyth 6y ago

Say what you want about Steve Balmer but he had the right attitude towards that https://www.youtube.com/watch?v=kHI7RTKhlz0 https://www.youtube.com/watch?v=kHI7RTKhlz0

JoeAltmaier 6y ago

Consider the cost of lines of code in a solution. Double the lines means double the time spent to simply type them in. Double the time later to read them. Probably many more times than double to re-understand them. Double the time to explain them. Double the compile time. Execution time is probably around double. It's not just twice as good to write shorter code. Its something like 64X as good. By some ways of thinking.

Jtsummers 6y ago
It's definitely a compounding issue as you grow and shrink SLOC. One bit of code I received was somewhere in the range of 5-10k SLOC when handed to me. I reduced it to around 1k SLOC. The original included numerous duplications, had a function that was itself on the order of 1-2k SLOC, was miserable to extend (which path do I need to follow to insert this new conditional? which paths will be impacted if I remove this conditionals?). Fortunately it wasn't shipped code, but it was useful for testing the embedded system. My refactoring involved, first, re-coding one of the larger, outer if-else-if sequences as a simple switch/case. This quickly revealed which variables were common to a large number of the branches and could be brought to a higher level of scope. Then common series of statements were parameterized and extracted to functions (preambles and postambles, setup and teardown, if you will). Several hundred lines were replaced with something like one 20-line function which took a single parameter and one call to it with the parameter that was previously evaluated through some hairy if-else-if sequence. Once completed, new test sequences could easily be coded up or were available because there was already a path that led to it, you just had to feed it a different value or series of values to trigger that path. Then we could automate the whole thing because we knew what the parameters were that clearly led to each branch. In the end the code was 5-10x smaller, but immensely more valuable.

everybodyknows 6y ago

The management psychology side of this wants a sequel from some veteran who was in the meetings and is now ready to confess: > ... wrote in the number: -2000. > I'm not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied. Bill — but what about the rest of the team? The devil’s answer: They were expected to keep supplying the number, because line management was forwarding the stats up, having previously “sold” upper management on their value. And to admit error on such a fundamental is career-threatening.

Zelphyr 6y ago

I had a manager once tell a co-worker (who is easily one of the best programmers I have ever worked with), "There's no way this can work. There's not enough code." Why we keep promoting these people into positions of management is beyond me.

mynameisash 6y ago

"It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove." - Antoine de Saint Exupéry

noarchy 6y ago

There are still companies trying to impose metrics on software development. It isn't just lines of code, it may also include commits per day. And this isn't even taking into account various "Agile"-related metrics, like story points per sprint and the like. I wonder if we should name the companies who do this, or if it is fighting a losing battle? In the end, some management just wants to look at charts.

Zelphyr 6y ago
One of the greats is "number of bugs fixed". You're practically begging your less-than-ethical programmers to create silly bugs so they can "fix" them and get a cookie. Edit to add: This happens outside of programming as well. I know a guy who worked at AT&T as a DSL Installation & Repair tech. They had such a focus on how long techs spent on a given job (less time was encouraged, more time was penalized) that a lot of his co-workers would go to the DSLAM and snip a wire so that they would be called out the next day to fix the problem. He pushed back so heavily on the poor incentive of "getting your numbers up" that he eventually got written up for insubordination. We need a larger eye-roll emoji.
- quercusa 6y ago
  There's a old Dilbert to that effect. Wally: "I'm going to write myself a minivan!"
- Jtsummers 6y ago
  Of questionable ethics, at one office there was no reward for finishing a large number of tasks. But there was an implicit penalty for delays and the tasks were not properly segregated by effort. One of the testers had something like 300-400 test cases he was automating. The majority were simple, minutes to an hour of work, and easily sharing common code. 50 or so were large, taking several days or even a couple weeks of effort. Even though he, technically, could have finished the majority of test cases in a couple weeks, he knew that they'd expect that pace to continue. Consequently, he left all those small cases for later. It was simpler this way than fighting the misperception that all the work was of similar effort. If he ever seemed to be falling behind, he'd churn out 20+ test cases on Friday and the reports for the week looked good to management. I've never done this myself, but I've seen developers do similar things rather than fight management. Measuring and rewarding the right things is important.

carapace 6y ago

> My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. ~Dijkstra (1988) "On the cruelty of really teaching computing science (EWD1036). https://en.wikiquote.org/wiki/Edsger_W._Dijkstra https://en.wikiquote.org/wiki/Edsger_W._Dijkstra

lambda_obrien 6y ago

Is there anywhere which optimizes for LOC count today? I figure everyone knows by now LOC is a bad metric.

ChrisMarshallNY 6y ago

The best code is the code I don't write. As a manager, I would value a developer that spent a week, refining a small, high-quality, robust and performant class, than one that churned out rococo monsters in a short period of time. I tend to write a lot of code, and one of the things that I do, when I refactor, is look for chunks I can consolidate or remove. OO is a good way to do that. It's a shame it's so "out of fashion," these days. The ability to reduce ten classes into ten little declarations of five lines each, because I was able to factor out the 300 lines of common functionality, is a nice feeling. An interesting metric for me, is when I run cloc on my codebase. I tend to have about a 50/50 LoC (Lines of Code) vs. LoC (Lines of Comments).

Havoc 6y ago

You can tell it’s folklore by the part where they stop making him fill out the form 3/10 for realism

mangomania 6y ago

Good job!

dang 6y ago

If curious, past threads: -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)

jansan 6y ago
Was there really a 5+ year gap since the last thread? We should not let this happen again.
- dang 6y ago
  Perhaps someone will find other cases of this story showing up.
- utopcell 6y ago
  (-:
- taneq 6y ago
  So you’re saying the last thread was -2000 days from now?
  - pizza 6y ago
    1911 days ago.. so, yeah, within 5% accuracy!
- gus_massa 6y ago
  There are many more, but dang only posted the ones that got traction https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=2000%20%22Lines%20of%20Code%22&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... (last one was 20 days ago, 1 point, 0 comments)

methyl 6y ago

If you want to read about flawed metrics, how they affect the production and what to do about it in a form of interesting novel - check out The Goal by Elijjahu M. Goldratt. It's a classic, but gets recommended seldom for how good it is.

csours 6y ago

Disclaimer: I work for GM - this is solely my own opinion. Whenever I hear people in the automotive industry boast about the complexity and lines of code in vehicles I weep and shake my head.

Jtsummers 6y ago
It happens in aerospace as well. I had a manager boasting, once, about the skill of his people and the product with something like, "This was 100k lines of code!". In working with some of those people (a couple specific individuals) later I realized that the 100k lines of code was probably reducible to 10-20k lines of code if it was anything like their later work. The code they wrote worked, but was not extendable or comprehensible by anyone but them, and I spent more time refactoring and shrinking their work than actually extending it.
Yeroc 6y ago
I heard Elon Musk state in an interview that they gave every new line of code 1 point and every deleted line of code 2 points so clearly at least Tesla seems to value fewer lines of code. Reference: https://youtu.be/YAtLTLiqNwg?t=953 https://youtu.be/YAtLTLiqNwg?t=953

jansan 6y ago

Aaah, now I understand how people came up with the strange idea to place opening curly brackets into a new line. Suddenly this all makes sense.

beaconstudios 6y ago

This take is probably going to be controversial here, but I suspect that most metrics don't accomplish anything beyond giving control freak managers a sense of control or insight. Most complex processes can't be reduced to a handful of simple variables - it's oversimplification at its worst. The best you can do is use metrics for a jumping-off point for where something /might/ be going wrong and thus start engaging with actual humans (or reading code/logs/some other source of feedback). Too often I've had to deal with management who go straight from metrics to decisions and end up making bad decisions (or wasting everyone's time shuffling paper to generate good looking metrics).

andrewflnr 6y ago
> This take is probably going to be controversial here, but... You then state what seems to be the mainstream view on HN. Certainly I don't see it as controversial, just kind of obvious
- beaconstudios 6y ago
  I figure it to be controversial because I see the HN crowd as leaning more towards maths/reductionism/measuring than intuition/holism/feedback and while I'm specifically levying the anti-quantification argument against managers in this case it also applies to that approach in general.
  - andrewflnr 6y ago
    Yeah, but OTOH we're mostly software people who have seen first-hand what happens when you try to apply naive metrics to software. In other fields you're more likely to be right.
  - SamBam 6y ago
    A large percent of HN are software developers, and no developer wants to be held to some metric by some non-developer boss.
bawolff 6y ago

tregoning 6y ago

Related :) https://twitter.com/tregoning/status/1286329086176976896 https://twitter.com/tregoning/status/1286329086176976896

Twirrim 6y ago

Years ago I worked for an ISP & managed hosting company as third line support. 1st and 2nd line support were pretty good, and would handle a lot of the cases that came through. Generally by the time it'd reach us, it was something requiring more in depth troubleshooting. They introduced a metric to measure ticket performance. The rough idea was "faster it's resolved, the better" (reasonable measure, if you're also tracking customer satisfaction), combined with "fewer interactions with customer the better" which was an absolutely stupid way to measure performance. About a month after it came out, we were getting chewed out for our "conversion score" being low. Too many interactions with customers, and tickets taking a while to handle. No shit, we're the top tier of support. If it got to us it was bound to take time to resolve, and almost certainly involved a lot of customer interaction. One of the engineers in the team managed to dig up how to get a "conversion" rate report up for any support engineer, though not the code that generated the figures, and very quickly realised that the way to get 100% conversion rate was just to resolve and immediately re-open the ticket as soon as you picked it up. We all promptly started doing that, and they stopped chewing us out. If you incentivise the wrong behaviour, you're going to get results you likely don't want.

suhlig 6y ago
„When a measure becomes a target, it ceases to be a good measure.“ https://en.wikipedia.org/wiki/Goodhart's_law?wprov=sfti1 https://en.wikipedia.org/wiki/Goodhart's_law?wprov=sfti1

sanj 6y ago

I once removed 4 lines of code. The change, annualized, was somewhere around $12M in profit. I'm still pretty proud of making -$3M/LOC!

einpoklum 6y ago

More than the story itself, the website: https://www.folklore.org/ https://www.folklore.org/ is packed with stories which will make you smile, cry, or more enlightened. Or all of the above at the same time.

TheDudeMan 6y ago

> they stopped asking Bill to fill out the form, and he gladly complied. Compiled with what? Can one comply with an absence of request?

Scarblac 6y ago

Those few days that I managed -1000 lines of real code are among the happiest work-related days I had. It feels so good to find a simple solution that enables you to remove so much.

blunte 6y ago

One of my tasks as a young developer was to make a shell script faster. The systems engineers (who used this script to setup and configure large scale network management systems) were complaining that the "menu" took 60 seconds or more between selections. Ok, sure, sounds easy. Then I opened the script... 9000 lines. After reading and understanding what it was supposed to do, I rewrote it in 1500 lines (still basic SunOS unix shell code), and with reasonable use of internal data structures for caching so only the first menu visit required a time hit. Beyond that, it was 1 second for menu selections. To say the system engineers were pleased would be an understatement. My manager was pleased but also displeased, because he was the author of the 9000 line monstrosity.

deleted 6y ago

[deleted]

h0mie 6y ago

jkj

chrisweekly 6y ago

In general, code is a liability, not an asset.

sswam 6y ago

We could measure lines of code added, multiplied by quality of code as determined by some coding standards or occasional peer review, and credit for removing inferior code. I guess it needs thought. I've noticed, as a programmer myself, that my quantum nature does not enjoy being measured in this way.

TimedToasts 6y ago

Around the turn of the Willennium, I beat a long-standing "Most C LOC approved in a month" record at Old School Big Name Inc. and you are not taking it away from me. No one had come close to that record in a decade and I beat it and you can kiss my keyboard if you think I was lazy about it. Harumph, I say!

bdg 6y ago

Is it just me or does the average engineer in most companies produce something like 150 lines of code per day when averaged over a year?

bjoli 6y ago

I have had code I wrote replaced by something that was 30% smaller, faster and more stable. It was a good and humbling experience. I contributed an inliner to a language about ten years ago. Inlining is a problem that might seem easy at first, but for me it was like trying to restrain a rabid dog on a leash. I was pretty damn pleased with the end results and it served the language implentation well until about 2015. Then someone with an actual understanding of the problem worked on it for a week and produced something that I would describe as poetry.

crsr 6y ago

Bill Atkinson reminds me of Gilfoyle from Silicon Valley

ne38 6y ago

we must measure edited lines not the difference between numbers of lines after and numbers of lines before! It is like if you work in money exchanges: there is buying and selling.

deleted 6y ago

[deleted]