51 ms·

-2000 Lines of Code (2007)

256 points by colinprince 3y ago

pietroppeter 3y ago
I guess somehow remarks about lines of code being (mostly) meaningless to measure programmers’ productivity feels related to the extent of the impact AI will have on software engineering.
1letterunixname 3y ago
+KLoC is a terrible KPI that optimizes for complexity, waste, and artificial job security-seeking behaviors.
- deleted 3y ago
  [deleted]
- ck45 3y ago
  It‘s Goodhart‘s law: "When a measure becomes a target, it ceases to be a good measure"
  - enva2712 3y ago
    I’d interperet the cease qualifier in goodhart’s law to require the measure to be good in the first place, but I think SLOC is a negative indicator regardless of whether it’s a target I think there are parallels between Deutsch’s ideas about explanation and the concept of coincident vs inherent complexity
  - Almondsetat 3y ago
    This also goes for Goodhart's law itself
    - arrowsmith 3y ago
      https://xkcd.com/2899/ https://xkcd.com/2899/
      - deleted 3y ago
        [deleted]
      - samatman 3y ago
        This is indeed funny, but the 'tribune' role of finding bad law/process and advocating for its removal is missing from most government, corporate or otherwise, and that's bad. It is in fact the same phenomenon as treating +SLOC as a proxy for productivity. When everyone is rewarded for adding process, but it isn't anyone's job to remove it, a system inevitably ends up with too much process.
  - arrowsmith 3y ago
    Lines of code is a bad measure even if it's not a target.
- threatripper 3y ago
  But they ARE a KPI that is easy to understand and measure.
  - _ZeD_ 3y ago
    they are not a KPI in the first place. loc is not a performance index of any kind.
    - bertylicious 3y ago
      Edited: wrong parent
  - solumunus 3y ago
    How can it be a KPI if it doesn’t measure performance?
    - threatripper 3y ago
      If you type faster you get more LOC. If you slack off all day you get zero. It does measure something, not necessary something useful but zero LOC indicates trouble.
      - drchickensalad 3y ago
        That's such a limited view which creates terrible incentives. If you work insanely hard solving a problem, you often end up with 0 loc + an incredible amount of understanding. If you slack off all day then spend an hour writing a bunch of sloppy code, you have way more loc than someone who worked all day to refine some simple clear performant code (which is then read 500 times before it's changed, hence the time is earned back with interest). These scenarios don't have to happen for the disincentive to still affect the work people do; there's a continuous problem from the baseline to these extremes.
      - datavirtue 3y ago
        I'm on day two of an analysis, zero code written. I don't know what, if anything, needs written. If I had to pound out something to keep from being zero it would be fraud.
- eloisant 3y ago
  It's obvious today to everyone, unfortunately we replaced that by KPI that are no better.
chii 3y ago
> they stopped asking Bill to fill out the form which is only possible because he's so important. imagine doing this as a stack-ranked IC in an org like AWS. The old days of a software as an artisanal craft is long over imho.
- quelltext 3y ago
  I'm by no means important in my org but when something appears like a shitty idea I will raise that (like other ICs around me) and more often than not it works out fine. I'll agree to give something a shot but if it doesn't work it doesn't work and my managers so far have all realized that a bit into the trial period. Reading comments like yours, I guess I should value my work environment more.
  - bickeringyokel 3y ago
    The question is really more do they actually act on the feedback on a regular basis?
  - xiphias2 3y ago
    If you want to see an extrema of people being afraid to speak up, just look at the Gemini image examples in a company that in theory encourages people to speak up. There are always topics that are exceptions.
    - pbhjpbhj 3y ago
      If you're OOTL on Google Gemini ML-based content creator then https://blog.google/products/gemini/gemini-image-generation-issue/ https://blog.google/products/gemini/gemini-image-generation-... is a pretty good summary. Ostensibly it appeared to be tuned to be racist. Maybe Google encourages people to speak up but also has a culture of racism?
  - eloisant 3y ago
    It's not about speaking up on a shitty idea, it's about not playing the game on a tool used to measure employee performance. That's a big difference. Especially because here we're talking about someone whose performance and contributions were very clear to everyone. Otherwise, he might have been seen like an underperformer by managers.
bickeringyokel 3y ago
The cynic in me believes managers actually don't want good metrics because then they have evidence of their bad leadership.
- hinkley 3y ago
  It’s why they love claiming “culture fit” on anyone older than them. 28 year old managers feeling threatened by 30 year old employees.
  - bickeringyokel 3y ago
    Anecdotally, I have not found much correlation between age and management style. I have had bad managers of all ages! I have had one good manager though, and it's pretty obvious what made them great. First is they listen to what problems you have and actually help you do your best work. Secondly, they protect you from the other bad leaders at the company. Thirdly, they work too hard.
    - richrichie 3y ago
      Work too hard?
      - mangamadaiyan 3y ago
        GP probably meant to type "they too work hard", I guess?
      - pooper 3y ago
        Maybe that is a relative thing? As in the norm is bad managers delegating everything to a fault, so a good manager by comparison works too hard? Or maybe it is an availability thing? My personal experience is I'm much more motivated to work If my manager is highly available from early morning to late evening.
- deleted 3y ago
  [deleted]
praptak 3y ago
The largest impact is sometimes asking simple questions (how are you going to handle X?) which leads to not building something. When this something hasn't ever had a chance to work, you saved the whole cost of trying to build it. This is not only impossible to measure as a numerical metric but also makes you enemies. Kudos to those who dare to do that anyway.
- anonzzzies 3y ago
  > The largest impact is sometimes asking simple questions (how are you going to handle X?) which leads to not building something. Which is why I teach new people to have that loop in your head and not start pounding the keyboard at high velocity. The people who find programming to be akin to fast typing show very interesting equivalence with LLMs; fully write/remove/write/remove etc of not very well written code.
  - atoav 3y ago
    Mhh for me it is always a combination of the two. I like making a good high level plan, but for certain problems it is better to make the plan as you go, because you can't fully understand the shape of the problem and the potential solutions as you start. Sure maybe that means your first code sucks and is a prototype that should be replaced, but if you are aware of that and don't pretend otherwise I don't see why this wouldn't be okay.
- drpixie 3y ago
  When I managed software for a large corporate, I kept a box of pencils on my desk. For around 1/2 the information requests that came through the department (always very important, we need the info now, it will save/make big dollars) the obvious answer was "Work it out from the info you already have. You've got a calculator and spreadsheet - would you like a pencil?" Better to avoid the system handling X than having multiple special cases bulking up the systems, most of which only get used once in a blue moon. No one knows the special cases/programs are there, or what actually do. Even if well documented, no one spends the time required to know what's available. So most of those special features are actually waste of time.
hinkley 3y ago
Gave myself RSI deleting <600 LOC with vi. On the plus side I replaced an O(n²) algorithm with a faster one in the very next commit. Needed to get rid of the ninety copies of the same bad idiom first.
- hsjsbeebue 3y ago
  600dd:w shouldn’t cause RSI ;)
  - hinkley 3y ago
    It was five to six lines of code repeated in half a dozen spots in a dozen files, with different variable names, and different arguments. And I wasn’t deleting them, I was replacing them with the same function call.
    - aidos 3y ago
      That’s got “macro” written all over it.
      - jraph 3y ago
        That's a sed /d of course. Or a "Replace all in folder" in any decent code editor. Or a sufficiently efficient "extract to method" on a decent IDE, that notices the different occurrences even with renamed variables. Unless those lines of code were subtly edited all over the place and needed careful and subtly different replace for each occurrence, or at last review because that's what's truly evil with duplicated code. It's forks that diverged to maintain N times in your codebase.
- selcuka 3y ago
  > Gave myself RSI deleting <600 LOC with vi. Why? Didn't you know the shortcut `d600d`? /s
- mehdix 3y ago
  I was giving myself RSI by deleting <12000 lines of copied comments (only misleading noise, explaining what was happening) and <4000 LOC (replaced with a 120 LOC in a single fn) when I reverted to using regex while sanitizing a badly bloated codebase. Can feel you right there.
joaquincabezas 3y ago
this keeps coming… recently there’s been a bit of debate between Milvus and Qdrant on this topic: https://www.linkedin.com/posts/yujiantang_how-can-you-judge-how-robust-or-feature-rich-activity-7171228128189636608-tsqs?utm_source=share&utm_medium=member_ios https://www.linkedin.com/posts/yujiantang_how-can-you-judge-...
khazhoux 3y ago
Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the commits. This can reveal potential problem areas for the manager to investigate with the engineer. You might find that the engineer has very few, very small commits compared to their peers, and then upon looking at the actual code you may find that the code seems rather trivial. This would warrant a conversation. Why have they reported at every standup the last six months that they're stuck behind very tricky problems when the commit history shows only a couple of seemingly simple changes? Maybe the problem really was tricky, but maybe the engineer is struggling and doesn't realize it. So let's find out. So while no one should be reduced to a simplistic LOC metric, and recognizing that more code can mean more bloat, we can't pretend that the amount of code that a developer writes is devoid of any meaning, as if it were just a random number.
- lakpan 3y ago
  Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC could have taken hours to discover.
  - xandrius 3y ago
    Exactly! I've myself spent days investigating an issue only happening on a specific Android device (but used by an important client) only to find that the solution was something along the lines of using "opacity: 0.1" instead of 0. That bug was left unfixed for months but now it's solved. Should I have received a talk because of that? (Of course the commit would have had at least 10 LOC more, explaining the reasons and providing references to future devs/self)
    - khazhoux 3y ago
      > Should I have received a talk because of that? Of course not. But, if your commit history for last 6 months is just one or two of those one-line changes a month, that might hint that there’s a problem.
userbinator 3y ago
A corresponding thought-experiment is to consider the results of the opposite situation: if a manager read this article, and simplemindedly decided to measure by lines of code removed instead. Would that make things better or worse?
- xandrius 3y ago
  Definitely no new features. If the product is "finished" then it would probably be equal or better (otherwise the negative LOC change wouldn't make it to prod). But most products are ever evolving (that's why we have the luxury of remaining on the same project for years), so just negative contributions will invariably not add anything.
- anonzzzies 3y ago
  Easier to be gamed depending on the company and method of measuring; let llama dream up code that looks fine, add some code so the code has no actual effect, commit, remove at some time later. Any measuring of this kind is pretty much useless you have solid code review practices in general place (which, unlike people here like to believe, is a rarity). But with good reviews, underperformance and gaming the system would also be caught so you would have less reason to implement metrics like this.
- praptak 3y ago
  Worse, because codegolfing the entire codebase is undesirable.
- samatman 3y ago
  Any line-based metric should be suspect, but 'delta-SLOC' is probably the least bad. I would count added lines and removed lines separately, so a +50,-150 patch would be 200 ΔSLOC. This isn't a good measure of productivity, especially not in isolation, but it's a reasonable napkin-math metric of change. A developer with a high ΔSLOC count may or may not be more productive than a peer who has a week or two of no ΔSLOC at all, depending on what that peer is up to, but the first of these is definitely changing the codebase more than the second, during the measured time span.
hsjsbeebue 3y ago
The moral: even if you are smart as Einstein you are still an employee and need to do employee things.
- datavirtue 3y ago
  If Einstein was pressured by metrics we would have never heard of him.
  - michaelcampbell 3y ago
    I suspect he was... as a patent clerk. And that may be why we never heard of him THEN.
    - renox 3y ago
      > I suspect he was... as a patent clerk. I believe he managed to work on patents only in the morning..
octopusRex 3y ago
Microsoft and IBM Lines of code clash >In the PBS TV series based on Bob Cringely's Accidental Empires, there is a sequence where Steve Ballmer describes the experience of co-developing OS/2 with IBM, how the whole thing became a fantastic clash of corporate culture, with Microsoft having the small-company attitude of getting things done, and IBM being focused on internal measures primarily KLoCs, that is thousands of lines of code as a measure of programmer productivity. "All they cared about," raves Ballmer, "was KLoCs and KLoCs and KLoCs." IBM, apparently, did not care whether the code was any good as long as there was a lot of it. https://ubiquity.acm.org/article.cfm?id=1022357 https://ubiquity.acm.org/article.cfm?id=1022357
- exitb 3y ago
  For a bit of context, the TV series this refers to is called „Triumph of the Nerds” and it’s a great watch, even today (maybe ever more so?).
  - sourcecodeplz 3y ago
    Found it on youtube: https://www.youtube.com/watch?v=toSRmKKiosQ https://www.youtube.com/watch?v=toSRmKKiosQ
- patrickmay 3y ago
  Not just IBM. A few years back I worked on a large project with one of the big international consulting companies as the prime contractor. They threw a party for the whole team when the codebase hit one million lines of code. Those of us who knew better treated the "celebration" as a wake.
  - pixl97 3y ago
    It's terrifying working around fintec and seeing how many 20MLOC monoliths are laying around and the code quality issues that crop up in them.
    - helpmefindpurp 3y ago
SillyUsername 3y ago
Bill Atkinson, of Atkinson Dither fame. https://beyondloom.com/blog/dither.html https://beyondloom.com/blog/dither.html
- jameshart 3y ago
  Bill Atkinson wrote QuickDraw (the graphics libraries that underpinned the Lisa and Mac UI), and MacPaint, and HyperCard. Along the way he kept having to both invent new ways for user interfaces to work, and new ways to write software to solve for them. There's a kind of synergy that emerged out of the fact that he was optimizing both for 'can be done quickly in the hardware available on the Mac', and 'provides a great user experience', which means that his fingerprints are all over the aesthetic of the old black and white Mac. That dither style is another example of that kind of marriage of algorithmic genius and aesthetic sensibility. And it shows up in things like the 'marching ants' selection boundary (https://en.wikipedia.org/wiki/Marching_ants https://en.wikipedia.org/wiki/Marching_ants). Or the way lots of user feedback in the classic Mac UI comes in the form of inverting pixels (text selection, menu highlighting, the way buttons appear during a mouse-down, the boundary of a window while it's being dragged), because drawing over something in XOR mode was a great way to generate that effect. The way he approached putting these tools together in QuickDraw also had the effect of things like his famous conversation with Steve Jobs about rounded rectangles (https://www.folklore.org/Round_Rects_Are_Everywhere.html https://www.folklore.org/Round_Rects_Are_Everywhere.html) manifesting as it being as easy to draw a rounded rectangle as a square one in QuickDraw, which led to them showing up everywhere in the operating system. The success of the Mac UI was not just that it looked good; it was in large parts that Bill Atkinson made a really cleaver, small set of tools that made making things that looked good easy to make. Susan Kare's amazing icons wouldn't be nearly as fondly remembered if Bill hadn't built the tools that made it easy to drop 32x32 pixel masked bitmaps into the UI and invert them when you clicked on them.
Taniwha 3y ago
The real story here is that sometimes you start a project and don't really know exactly where you're going, as you get into it you start to understand both the problem and the answer you want much better - and then yes, you can rip a chunk out and replace it with something smaller and better And don't forget, these guys had to fit everything, including those -2000 lines of code (assembler code) into 64kbytes of ROM - there was intense pressure to make stuff smaller
- mananaysiempre 3y ago
  QuickDraw is mostly written in Pascal with critical loops in assembly[1,2]. I’m also not sure if it’s in actually in ROM or on the boot floppy. (Incidentally, Wikipedia tells me the Lisa’s ROM was 16K.) [1] https://computerhistory.org/blog/the-lisa-apples-most-influential-failure/ https://computerhistory.org/blog/the-lisa-apples-most-influe... [2] https://computerhistory.org/blog/macpaint-and-quickdraw-source-code/ https://computerhistory.org/blog/macpaint-and-quickdraw-sour...
  - Taniwha 3y ago
    I think it started out in ROM, it has low core jump vectors so that portions can be replaced (rather than just the whole thing) I worked designing Mac graphics accelerators back in the day, we hooked them up by replacing bits of QD through these vectors. So over time rom fixes got made and some of it would have come off of disk If you follow that second link you'll find a zip file with quickdraw source in it, you'll find that while there is a little pascal (.p files) most of the core is assembler (.a files)
    - Taniwha 3y ago
      Also putting display core routines in ROM was important because RAM access was slower (because the display used 1/2 the RAM bandwidth)
      - bcrl 3y ago
        Good point. The Amiga did the same thing in the Amiga 500 and 2000. The Amiga 1000 would have if the operating system had been more stable at time of release. It also saved a significant chunk of RAM as the 1.x releases of AmigaOS used 256KB ROMs while 2.x on were 512KB ROMs.
deleted 3y ago
[deleted]
JoeAltmaier 3y ago
Same nonsense at Convergent in the early days. Jim Frandeen worked on tightening up the OS, saved like 10% memory footprint. Likewise, a negative code count. That manager actually quit. My own experience was changing a 10K line module with a template in one page. Put some angle-brackets in about 100 references which left a net -9900 LOC
zac23or 3y ago
Counting lines of code as a production metric is very stupid. I remember solving an unsolvable 20 years old bug with a line of code, another 3 years old with a order by. How to measure the impact of a line of code? And in my experience, bad programmers write a lot more code... I will never forget the story[1] of a Microsoft developer rewriting a piece of IBM code that had 33 thousand characters, after rewrite ... 220. This generated a war because MS's work was... negative. [1] https://archive.org/details/bigbluesunmaking00carr/page/4/mode/2up https://archive.org/details/bigbluesunmaking00carr/page/4/mo... page 101
- bdw5204 3y ago
  Using production metrics as a whole is very stupid and a good way to get devs to optimize for the metrics rather than quality work. A contemporary example would be a company that promotes for "impact" (i.e. launching new products) which is a great way to have a bunch of failed products that nobody maintains!
  - gabrielhidasy 3y ago
    I know at least a few many-hundred-billion dollar companies that fit that description...
  - barcist 3y ago
    The trick is to align the metrics with company goals. It's not easy, but not impossible either. For example, if quality is your goal, then the metric you give your devs is "number and severity of bug reports coming in from customers". If unsatisfied feature requests are part of that number, then the devs have to strike a balance between churning out features and preventing bugs (and fixing discovered ones). Obviously your customer support needs a different metric.
    - rightbyte 3y ago
      Ye and you end up with blame games and hot potatoes being passed around. Bug count metrics incentives "don't touch anything" and coding with feuture flags and globals to limit the scope of change and circumvent the architecture. Like, just don't do metrics and have the management actually review the work of their subordinates if that is important to follow up on. Actual management can't be compressed to a acting on some scalar values.
AdrianB1 3y ago
I do a lot of code review for SQL. One thing that I always to is reduce the number of lines of code, usually by ~10% on the first read. I need to focus not to become a target :)
cmsefton 3y ago
This comes up often! A few previous discussions: https://news.ycombinator.com/item?id=33483165 https://news.ycombinator.com/item?id=33483165 (2022) https://news.ycombinator.com/item?id=26387179 https://news.ycombinator.com/item?id=26387179 (2021) https://news.ycombinator.com/item?id=10734815 https://news.ycombinator.com/item?id=10734815 (2015) https://news.ycombinator.com/item?id=7516671 https://news.ycombinator.com/item?id=7516671 (2014) https://news.ycombinator.com/item?id=4040082 https://news.ycombinator.com/item?id=4040082 (2012) https://news.ycombinator.com/item?id=1114223 https://news.ycombinator.com/item?id=1114223 (2010) https://news.ycombinator.com/item?id=1545452 https://news.ycombinator.com/item?id=1545452 (2010)
hyperman1 3y ago
There is a deeper lesson here: Someone was thinking of lines of code as an asset, not a cost. It's a an error you also see in junior programmers writing reams and reams of code. The lesson is a harsh one for us code lovers, at least it was for me: Code is a means to an end, and an expensive one at that. The best code is the code never written. Our job is to solve problems, not to write code. You can use LOC as a crude measure of progress, in the same way as tons of concrete used is a crude measure of progress when building a skyscraper.
- datavirtue 3y ago
  As a developer few things make me glow like deleting hundreds of lines of code that have been replaced by simplicity.
- gabrielhidasy 3y ago
  Not even that, I'm not a civil engineer, but it looks pretty hard to add a ton of concrete without really helping a skyscraper, but I could add a few thousand lines of code without improving a system one bit, and even more lines to make the system slower, more complex, and still not add any functionality. LoC is about as good a measure of a system quality as weight is for an aircraft project.
  - CrazyStat 3y ago
    > LoC is about as good a measure of a system quality as weight is for an aircraft project. This is a very good an analogy. A plane has to weigh something, but the absurdity of measuring how much progress you’ve made building a plane by how much weight you’ve added is immediately obvious.
  - margalabargala 3y ago
    > Not even that, I'm not a civil engineer, but it looks pretty hard to add a ton of concrete without really helping a skyscraper. I am also not a civil engineer but I can think of a lot of ways to add concrete to a skyscraper in ways that are somewhere between nonhelpful and burdensome.
  - 3y ago
HarHarVeryFunny 3y ago
If you measure productivity by LOC, then generally what you will get is lots of LOC. Cut and paste is easy if that's what makes you look good. Of course what companies should really be incentivizing is well written code that is easy to maintain and extend, not bloated cut-n-paste garbage.
- araes 3y ago
  And when somebody figures out how to metricize "well written" then that will turn to fecal matter. Re: Goodhart's Law [1] (admittedly meant to be economic, yet applies to most metrics). Also related to Enshittification (see fecal matter), the platform shifts, no longer prioritizes quality, and instead shifts to whatever "well written" is defined as. LLM's and especially online song choice algorithms have a heavy dose of this. "Make whatever pop music says is 'well written'" You have included all the keywords necessary to SEO your billboard submission.
  - passion__desire 3y ago
    Where does Uncle Bob fit into this? Because he sure does love to give advice How small a function should be? https://youtu.be/rXjf8eiGsSI https://youtu.be/rXjf8eiGsSI
    - araes 3y ago
      I think I'm totally missing the reference (apparently the Robert in the video?). I thought it was Bob's your uncle (instructions complete), or Uncle Bob the photographer (who doesn't know how to use his own equipment). Pretty sure its not a T-800 Terminator or smoking pot like Bob Marley reference. Also, totally feel like an LLM doing the %chance this word game.
    - HarHarVeryFunny 3y ago
      Google Robert Martin => "first chairman of the Agile Alliance". Wouldn't the really agile thing be to get rid of alliances and chairmen in charge of telling people how to develop software?
analog31 3y ago
This is what I always think of when someone tells me that AI will replace coders. I tell them: "A coder can only write about 100 lines of good code a day, but I look forward to when the AI can write 100 million lines of code a day."
continuational 3y ago
In evaluating software value, lines of code fall under the denominator.
sircastor 3y ago
For all the people dismissing lines of code as a metric, I want to point out that very early on a line of code was literally a CPU instruction. While there was certainly something to be said for efficiency of your subroutine, lines of code was not a totally unreasonable measurement of things that your program was doing. Obviously we get removed from that the more we abstract and well constructed code is different from lines of code, but I can see where they were coming from.
- deleted 3y ago
  [deleted]
- kbolino 3y ago
  One of those CPU instructions (or one class of them anyway) is called a jump. It allows you to move to a different instruction than the next one, including going backwards. There has always been reusability of already written code in digital computers. LOC was no more or less meaningful when code was written in assembly or machine language than it is today. It only measures something loosely correlated with progress toward completion and only if you know what done looks like.
gjkood 3y ago
Early in my career I once optimized an inherited 10,000+ line C program to less than 500 lines. It was a C program making SQL calls into a Sybase database. No, not because I had some brilliant insight but for the simple assumption that my predecessor may not have been aware of how to write functions or use parameters to supply variable data to the SQL query. They had literally written the same SQL statement inline with a couple of changed values in each SQL call. I just rewrote the code making the SQL call as a function call with bind variables as parameters into the function. All the replicated inline code was replaced with the function being called in a loop with the changed bind values supplied from an array.
- papichulo2023 3y ago
  Yooo, no params == no injection /s
- deleted 3y ago
  [deleted]
- walth 3y ago
  https://www.folklore.org/Discovered_Loops.html?sort=date?sort=date https://www.folklore.org/Discovered_Loops.html?sort=date?sor...
mig39 3y ago
Was this the original TPS report?
varjag 3y ago
It was a great write up in its time but has since become a goto cliche for people who can't write much code.
- sandspar 3y ago
  Article: "Did you know that geniuses like Einstein tend to be night owls?" Unemployed guy who wakes up at 11 a.m. every day: "I must be a genius!" Barba non facit philosophum: a beard doesn't make one a philosopher.
  - TRiG_Ireland 3y ago
    > But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown. ― Carl Sagan
torginus 3y ago
I never understood why is it when people talk about LoC of code written, they always use 'lines added - lines removed'. If I do a run 10km run and end up in the same place I started, it's not a 0km run.
- vacuity 3y ago
  I think a part of it is that dumb diff tools may record large diffs when the change in functionality is limited and the rest is more or less moving lines around. Like making if cond { ... return; } ... into if cond { ... return; } else { .... } But that's not comprehensive either.
cromulent 3y ago
It’s the wrong metric. We all know that. It’s like measuring a manager by “meetings attended” or something like that. The hard part is measuring the effectiveness of people whose output is realized in the future, not today.

256 points by colinprince 3y ago

I guess somehow remarks about lines of code being (mostly) meaningless to measure programmers’ productivity feels related to the extent of the impact AI will have on software engineering.

1letterunixname 3y ago

+KLoC is a terrible KPI that optimizes for complexity, waste, and artificial job security-seeking behaviors.

deleted 3y ago
[deleted]
ck45 3y ago
It‘s Goodhart‘s law: "When a measure becomes a target, it ceases to be a good measure"
- enva2712 3y ago
  I’d interperet the cease qualifier in goodhart’s law to require the measure to be good in the first place, but I think SLOC is a negative indicator regardless of whether it’s a target I think there are parallels between Deutsch’s ideas about explanation and the concept of coincident vs inherent complexity
- Almondsetat 3y ago
  This also goes for Goodhart's law itself
  - arrowsmith 3y ago
    https://xkcd.com/2899/ https://xkcd.com/2899/
    - deleted 3y ago
      [deleted]
    - samatman 3y ago
      This is indeed funny, but the 'tribune' role of finding bad law/process and advocating for its removal is missing from most government, corporate or otherwise, and that's bad. It is in fact the same phenomenon as treating +SLOC as a proxy for productivity. When everyone is rewarded for adding process, but it isn't anyone's job to remove it, a system inevitably ends up with too much process.
- arrowsmith 3y ago
  Lines of code is a bad measure even if it's not a target.
threatripper 3y ago
But they ARE a KPI that is easy to understand and measure.
- _ZeD_ 3y ago
  they are not a KPI in the first place. loc is not a performance index of any kind.
  - bertylicious 3y ago
    Edited: wrong parent
- solumunus 3y ago
  How can it be a KPI if it doesn’t measure performance?
  - threatripper 3y ago
    If you type faster you get more LOC. If you slack off all day you get zero. It does measure something, not necessary something useful but zero LOC indicates trouble.
    - drchickensalad 3y ago
      That's such a limited view which creates terrible incentives. If you work insanely hard solving a problem, you often end up with 0 loc + an incredible amount of understanding. If you slack off all day then spend an hour writing a bunch of sloppy code, you have way more loc than someone who worked all day to refine some simple clear performant code (which is then read 500 times before it's changed, hence the time is earned back with interest). These scenarios don't have to happen for the disincentive to still affect the work people do; there's a continuous problem from the baseline to these extremes.
    - datavirtue 3y ago
      I'm on day two of an analysis, zero code written. I don't know what, if anything, needs written. If I had to pound out something to keep from being zero it would be fraud.
eloisant 3y ago
It's obvious today to everyone, unfortunately we replaced that by KPI that are no better.

chii 3y ago

> they stopped asking Bill to fill out the form which is only possible because he's so important. imagine doing this as a stack-ranked IC in an org like AWS. The old days of a software as an artisanal craft is long over imho.

quelltext 3y ago
I'm by no means important in my org but when something appears like a shitty idea I will raise that (like other ICs around me) and more often than not it works out fine. I'll agree to give something a shot but if it doesn't work it doesn't work and my managers so far have all realized that a bit into the trial period. Reading comments like yours, I guess I should value my work environment more.
- bickeringyokel 3y ago
  The question is really more do they actually act on the feedback on a regular basis?
- xiphias2 3y ago
  If you want to see an extrema of people being afraid to speak up, just look at the Gemini image examples in a company that in theory encourages people to speak up. There are always topics that are exceptions.
  - pbhjpbhj 3y ago
    If you're OOTL on Google Gemini ML-based content creator then https://blog.google/products/gemini/gemini-image-generation-issue/ https://blog.google/products/gemini/gemini-image-generation-... is a pretty good summary. Ostensibly it appeared to be tuned to be racist. Maybe Google encourages people to speak up but also has a culture of racism?
- eloisant 3y ago
  It's not about speaking up on a shitty idea, it's about not playing the game on a tool used to measure employee performance. That's a big difference. Especially because here we're talking about someone whose performance and contributions were very clear to everyone. Otherwise, he might have been seen like an underperformer by managers.

bickeringyokel 3y ago

The cynic in me believes managers actually don't want good metrics because then they have evidence of their bad leadership.

hinkley 3y ago
It’s why they love claiming “culture fit” on anyone older than them. 28 year old managers feeling threatened by 30 year old employees.
- bickeringyokel 3y ago
  Anecdotally, I have not found much correlation between age and management style. I have had bad managers of all ages! I have had one good manager though, and it's pretty obvious what made them great. First is they listen to what problems you have and actually help you do your best work. Secondly, they protect you from the other bad leaders at the company. Thirdly, they work too hard.
  - richrichie 3y ago
    Work too hard?
    - mangamadaiyan 3y ago
      GP probably meant to type "they too work hard", I guess?
    - pooper 3y ago
      Maybe that is a relative thing? As in the norm is bad managers delegating everything to a fault, so a good manager by comparison works too hard? Or maybe it is an availability thing? My personal experience is I'm much more motivated to work If my manager is highly available from early morning to late evening.
deleted 3y ago
[deleted]

praptak 3y ago

The largest impact is sometimes asking simple questions (how are you going to handle X?) which leads to not building something. When this something hasn't ever had a chance to work, you saved the whole cost of trying to build it. This is not only impossible to measure as a numerical metric but also makes you enemies. Kudos to those who dare to do that anyway.

anonzzzies 3y ago
> The largest impact is sometimes asking simple questions (how are you going to handle X?) which leads to not building something. Which is why I teach new people to have that loop in your head and not start pounding the keyboard at high velocity. The people who find programming to be akin to fast typing show very interesting equivalence with LLMs; fully write/remove/write/remove etc of not very well written code.
- atoav 3y ago
  Mhh for me it is always a combination of the two. I like making a good high level plan, but for certain problems it is better to make the plan as you go, because you can't fully understand the shape of the problem and the potential solutions as you start. Sure maybe that means your first code sucks and is a prototype that should be replaced, but if you are aware of that and don't pretend otherwise I don't see why this wouldn't be okay.
drpixie 3y ago
When I managed software for a large corporate, I kept a box of pencils on my desk. For around 1/2 the information requests that came through the department (always very important, we need the info now, it will save/make big dollars) the obvious answer was "Work it out from the info you already have. You've got a calculator and spreadsheet - would you like a pencil?" Better to avoid the system handling X than having multiple special cases bulking up the systems, most of which only get used once in a blue moon. No one knows the special cases/programs are there, or what actually do. Even if well documented, no one spends the time required to know what's available. So most of those special features are actually waste of time.

hinkley 3y ago

Gave myself RSI deleting <600 LOC with vi. On the plus side I replaced an O(n²) algorithm with a faster one in the very next commit. Needed to get rid of the ninety copies of the same bad idiom first.

hsjsbeebue 3y ago
600dd:w shouldn’t cause RSI ;)
- hinkley 3y ago
  It was five to six lines of code repeated in half a dozen spots in a dozen files, with different variable names, and different arguments. And I wasn’t deleting them, I was replacing them with the same function call.
  - aidos 3y ago
    That’s got “macro” written all over it.
    - jraph 3y ago
      That's a sed /d of course. Or a "Replace all in folder" in any decent code editor. Or a sufficiently efficient "extract to method" on a decent IDE, that notices the different occurrences even with renamed variables. Unless those lines of code were subtly edited all over the place and needed careful and subtly different replace for each occurrence, or at last review because that's what's truly evil with duplicated code. It's forks that diverged to maintain N times in your codebase.
selcuka 3y ago
> Gave myself RSI deleting <600 LOC with vi. Why? Didn't you know the shortcut `d600d`? /s
mehdix 3y ago
I was giving myself RSI by deleting <12000 lines of copied comments (only misleading noise, explaining what was happening) and <4000 LOC (replaced with a 120 LOC in a single fn) when I reverted to using regex while sanitizing a badly bloated codebase. Can feel you right there.

joaquincabezas 3y ago

this keeps coming… recently there’s been a bit of debate between Milvus and Qdrant on this topic: https://www.linkedin.com/posts/yujiantang_how-can-you-judge-how-robust-or-feature-rich-activity-7171228128189636608-tsqs?utm_source=share&utm_medium=member_ios https://www.linkedin.com/posts/yujiantang_how-can-you-judge-...

khazhoux 3y ago

Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the commits. This can reveal potential problem areas for the manager to investigate with the engineer. You might find that the engineer has very few, very small commits compared to their peers, and then upon looking at the actual code you may find that the code seems rather trivial. This would warrant a conversation. Why have they reported at every standup the last six months that they're stuck behind very tricky problems when the commit history shows only a couple of seemingly simple changes? Maybe the problem really was tricky, but maybe the engineer is struggling and doesn't realize it. So let's find out. So while no one should be reduced to a simplistic LOC metric, and recognizing that more code can mean more bloat, we can't pretend that the amount of code that a developer writes is devoid of any meaning, as if it were just a random number.

lakpan 3y ago
Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC could have taken hours to discover.
- xandrius 3y ago
  Exactly! I've myself spent days investigating an issue only happening on a specific Android device (but used by an important client) only to find that the solution was something along the lines of using "opacity: 0.1" instead of 0. That bug was left unfixed for months but now it's solved. Should I have received a talk because of that? (Of course the commit would have had at least 10 LOC more, explaining the reasons and providing references to future devs/self)
  - khazhoux 3y ago
    > Should I have received a talk because of that? Of course not. But, if your commit history for last 6 months is just one or two of those one-line changes a month, that might hint that there’s a problem.

userbinator 3y ago

A corresponding thought-experiment is to consider the results of the opposite situation: if a manager read this article, and simplemindedly decided to measure by lines of code removed instead. Would that make things better or worse?

xandrius 3y ago
Definitely no new features. If the product is "finished" then it would probably be equal or better (otherwise the negative LOC change wouldn't make it to prod). But most products are ever evolving (that's why we have the luxury of remaining on the same project for years), so just negative contributions will invariably not add anything.
anonzzzies 3y ago
Easier to be gamed depending on the company and method of measuring; let llama dream up code that looks fine, add some code so the code has no actual effect, commit, remove at some time later. Any measuring of this kind is pretty much useless you have solid code review practices in general place (which, unlike people here like to believe, is a rarity). But with good reviews, underperformance and gaming the system would also be caught so you would have less reason to implement metrics like this.
praptak 3y ago
Worse, because codegolfing the entire codebase is undesirable.
samatman 3y ago
Any line-based metric should be suspect, but 'delta-SLOC' is probably the least bad. I would count added lines and removed lines separately, so a +50,-150 patch would be 200 ΔSLOC. This isn't a good measure of productivity, especially not in isolation, but it's a reasonable napkin-math metric of change. A developer with a high ΔSLOC count may or may not be more productive than a peer who has a week or two of no ΔSLOC at all, depending on what that peer is up to, but the first of these is definitely changing the codebase more than the second, during the measured time span.

hsjsbeebue 3y ago

The moral: even if you are smart as Einstein you are still an employee and need to do employee things.

datavirtue 3y ago
If Einstein was pressured by metrics we would have never heard of him.
- michaelcampbell 3y ago
  I suspect he was... as a patent clerk. And that may be why we never heard of him THEN.
  - renox 3y ago
    > I suspect he was... as a patent clerk. I believe he managed to work on patents only in the morning..

octopusRex 3y ago

Microsoft and IBM Lines of code clash >In the PBS TV series based on Bob Cringely's Accidental Empires, there is a sequence where Steve Ballmer describes the experience of co-developing OS/2 with IBM, how the whole thing became a fantastic clash of corporate culture, with Microsoft having the small-company attitude of getting things done, and IBM being focused on internal measures primarily KLoCs, that is thousands of lines of code as a measure of programmer productivity. "All they cared about," raves Ballmer, "was KLoCs and KLoCs and KLoCs." IBM, apparently, did not care whether the code was any good as long as there was a lot of it. https://ubiquity.acm.org/article.cfm?id=1022357 https://ubiquity.acm.org/article.cfm?id=1022357

exitb 3y ago
For a bit of context, the TV series this refers to is called „Triumph of the Nerds” and it’s a great watch, even today (maybe ever more so?).
- sourcecodeplz 3y ago
  Found it on youtube: https://www.youtube.com/watch?v=toSRmKKiosQ https://www.youtube.com/watch?v=toSRmKKiosQ
patrickmay 3y ago
Not just IBM. A few years back I worked on a large project with one of the big international consulting companies as the prime contractor. They threw a party for the whole team when the codebase hit one million lines of code. Those of us who knew better treated the "celebration" as a wake.
- pixl97 3y ago
  It's terrifying working around fintec and seeing how many 20MLOC monoliths are laying around and the code quality issues that crop up in them.
  - helpmefindpurp 3y ago

SillyUsername 3y ago

Bill Atkinson, of Atkinson Dither fame. https://beyondloom.com/blog/dither.html https://beyondloom.com/blog/dither.html

jameshart 3y ago
Bill Atkinson wrote QuickDraw (the graphics libraries that underpinned the Lisa and Mac UI), and MacPaint, and HyperCard. Along the way he kept having to both invent new ways for user interfaces to work, and new ways to write software to solve for them. There's a kind of synergy that emerged out of the fact that he was optimizing both for 'can be done quickly in the hardware available on the Mac', and 'provides a great user experience', which means that his fingerprints are all over the aesthetic of the old black and white Mac. That dither style is another example of that kind of marriage of algorithmic genius and aesthetic sensibility. And it shows up in things like the 'marching ants' selection boundary (https://en.wikipedia.org/wiki/Marching_ants https://en.wikipedia.org/wiki/Marching_ants). Or the way lots of user feedback in the classic Mac UI comes in the form of inverting pixels (text selection, menu highlighting, the way buttons appear during a mouse-down, the boundary of a window while it's being dragged), because drawing over something in XOR mode was a great way to generate that effect. The way he approached putting these tools together in QuickDraw also had the effect of things like his famous conversation with Steve Jobs about rounded rectangles (https://www.folklore.org/Round_Rects_Are_Everywhere.html https://www.folklore.org/Round_Rects_Are_Everywhere.html) manifesting as it being as easy to draw a rounded rectangle as a square one in QuickDraw, which led to them showing up everywhere in the operating system. The success of the Mac UI was not just that it looked good; it was in large parts that Bill Atkinson made a really cleaver, small set of tools that made making things that looked good easy to make. Susan Kare's amazing icons wouldn't be nearly as fondly remembered if Bill hadn't built the tools that made it easy to drop 32x32 pixel masked bitmaps into the UI and invert them when you clicked on them.

Taniwha 3y ago

The real story here is that sometimes you start a project and don't really know exactly where you're going, as you get into it you start to understand both the problem and the answer you want much better - and then yes, you can rip a chunk out and replace it with something smaller and better And don't forget, these guys had to fit everything, including those -2000 lines of code (assembler code) into 64kbytes of ROM - there was intense pressure to make stuff smaller

mananaysiempre 3y ago
QuickDraw is mostly written in Pascal with critical loops in assembly[1,2]. I’m also not sure if it’s in actually in ROM or on the boot floppy. (Incidentally, Wikipedia tells me the Lisa’s ROM was 16K.) [1] https://computerhistory.org/blog/the-lisa-apples-most-influential-failure/ https://computerhistory.org/blog/the-lisa-apples-most-influe... [2] https://computerhistory.org/blog/macpaint-and-quickdraw-source-code/ https://computerhistory.org/blog/macpaint-and-quickdraw-sour...
- Taniwha 3y ago
  I think it started out in ROM, it has low core jump vectors so that portions can be replaced (rather than just the whole thing) I worked designing Mac graphics accelerators back in the day, we hooked them up by replacing bits of QD through these vectors. So over time rom fixes got made and some of it would have come off of disk If you follow that second link you'll find a zip file with quickdraw source in it, you'll find that while there is a little pascal (.p files) most of the core is assembler (.a files)
  - Taniwha 3y ago
    Also putting display core routines in ROM was important because RAM access was slower (because the display used 1/2 the RAM bandwidth)
    - bcrl 3y ago
      Good point. The Amiga did the same thing in the Amiga 500 and 2000. The Amiga 1000 would have if the operating system had been more stable at time of release. It also saved a significant chunk of RAM as the 1.x releases of AmigaOS used 256KB ROMs while 2.x on were 512KB ROMs.

deleted 3y ago

[deleted]

JoeAltmaier 3y ago

Same nonsense at Convergent in the early days. Jim Frandeen worked on tightening up the OS, saved like 10% memory footprint. Likewise, a negative code count. That manager actually quit. My own experience was changing a 10K line module with a template in one page. Put some angle-brackets in about 100 references which left a net -9900 LOC

zac23or 3y ago

Counting lines of code as a production metric is very stupid. I remember solving an unsolvable 20 years old bug with a line of code, another 3 years old with a order by. How to measure the impact of a line of code? And in my experience, bad programmers write a lot more code... I will never forget the story[1] of a Microsoft developer rewriting a piece of IBM code that had 33 thousand characters, after rewrite ... 220. This generated a war because MS's work was... negative. [1] https://archive.org/details/bigbluesunmaking00carr/page/4/mode/2up https://archive.org/details/bigbluesunmaking00carr/page/4/mo... page 101

bdw5204 3y ago
Using production metrics as a whole is very stupid and a good way to get devs to optimize for the metrics rather than quality work. A contemporary example would be a company that promotes for "impact" (i.e. launching new products) which is a great way to have a bunch of failed products that nobody maintains!
- gabrielhidasy 3y ago
  I know at least a few many-hundred-billion dollar companies that fit that description...
- barcist 3y ago
  The trick is to align the metrics with company goals. It's not easy, but not impossible either. For example, if quality is your goal, then the metric you give your devs is "number and severity of bug reports coming in from customers". If unsatisfied feature requests are part of that number, then the devs have to strike a balance between churning out features and preventing bugs (and fixing discovered ones). Obviously your customer support needs a different metric.
  - rightbyte 3y ago
    Ye and you end up with blame games and hot potatoes being passed around. Bug count metrics incentives "don't touch anything" and coding with feuture flags and globals to limit the scope of change and circumvent the architecture. Like, just don't do metrics and have the management actually review the work of their subordinates if that is important to follow up on. Actual management can't be compressed to a acting on some scalar values.

AdrianB1 3y ago

I do a lot of code review for SQL. One thing that I always to is reduce the number of lines of code, usually by ~10% on the first read. I need to focus not to become a target :)

cmsefton 3y ago

This comes up often! A few previous discussions: https://news.ycombinator.com/item?id=33483165 https://news.ycombinator.com/item?id=33483165 (2022) https://news.ycombinator.com/item?id=26387179 https://news.ycombinator.com/item?id=26387179 (2021) https://news.ycombinator.com/item?id=10734815 https://news.ycombinator.com/item?id=10734815 (2015) https://news.ycombinator.com/item?id=7516671 https://news.ycombinator.com/item?id=7516671 (2014) https://news.ycombinator.com/item?id=4040082 https://news.ycombinator.com/item?id=4040082 (2012) https://news.ycombinator.com/item?id=1114223 https://news.ycombinator.com/item?id=1114223 (2010) https://news.ycombinator.com/item?id=1545452 https://news.ycombinator.com/item?id=1545452 (2010)

hyperman1 3y ago

There is a deeper lesson here: Someone was thinking of lines of code as an asset, not a cost. It's a an error you also see in junior programmers writing reams and reams of code. The lesson is a harsh one for us code lovers, at least it was for me: Code is a means to an end, and an expensive one at that. The best code is the code never written. Our job is to solve problems, not to write code. You can use LOC as a crude measure of progress, in the same way as tons of concrete used is a crude measure of progress when building a skyscraper.

datavirtue 3y ago
As a developer few things make me glow like deleting hundreds of lines of code that have been replaced by simplicity.
gabrielhidasy 3y ago
Not even that, I'm not a civil engineer, but it looks pretty hard to add a ton of concrete without really helping a skyscraper, but I could add a few thousand lines of code without improving a system one bit, and even more lines to make the system slower, more complex, and still not add any functionality. LoC is about as good a measure of a system quality as weight is for an aircraft project.
- CrazyStat 3y ago
  > LoC is about as good a measure of a system quality as weight is for an aircraft project. This is a very good an analogy. A plane has to weigh something, but the absurdity of measuring how much progress you’ve made building a plane by how much weight you’ve added is immediately obvious.
- margalabargala 3y ago
  > Not even that, I'm not a civil engineer, but it looks pretty hard to add a ton of concrete without really helping a skyscraper. I am also not a civil engineer but I can think of a lot of ways to add concrete to a skyscraper in ways that are somewhere between nonhelpful and burdensome.
- 3y ago

HarHarVeryFunny 3y ago

If you measure productivity by LOC, then generally what you will get is lots of LOC. Cut and paste is easy if that's what makes you look good. Of course what companies should really be incentivizing is well written code that is easy to maintain and extend, not bloated cut-n-paste garbage.

araes 3y ago
And when somebody figures out how to metricize "well written" then that will turn to fecal matter. Re: Goodhart's Law [1] (admittedly meant to be economic, yet applies to most metrics). Also related to Enshittification (see fecal matter), the platform shifts, no longer prioritizes quality, and instead shifts to whatever "well written" is defined as. LLM's and especially online song choice algorithms have a heavy dose of this. "Make whatever pop music says is 'well written'" You have included all the keywords necessary to SEO your billboard submission.
- passion__desire 3y ago
  Where does Uncle Bob fit into this? Because he sure does love to give advice How small a function should be? https://youtu.be/rXjf8eiGsSI https://youtu.be/rXjf8eiGsSI
  - araes 3y ago
    I think I'm totally missing the reference (apparently the Robert in the video?). I thought it was Bob's your uncle (instructions complete), or Uncle Bob the photographer (who doesn't know how to use his own equipment). Pretty sure its not a T-800 Terminator or smoking pot like Bob Marley reference. Also, totally feel like an LLM doing the %chance this word game.
  - HarHarVeryFunny 3y ago
    Google Robert Martin => "first chairman of the Agile Alliance". Wouldn't the really agile thing be to get rid of alliances and chairmen in charge of telling people how to develop software?

analog31 3y ago

This is what I always think of when someone tells me that AI will replace coders. I tell them: "A coder can only write about 100 lines of good code a day, but I look forward to when the AI can write 100 million lines of code a day."

continuational 3y ago

In evaluating software value, lines of code fall under the denominator.

sircastor 3y ago

For all the people dismissing lines of code as a metric, I want to point out that very early on a line of code was literally a CPU instruction. While there was certainly something to be said for efficiency of your subroutine, lines of code was not a totally unreasonable measurement of things that your program was doing. Obviously we get removed from that the more we abstract and well constructed code is different from lines of code, but I can see where they were coming from.

deleted 3y ago
[deleted]
kbolino 3y ago
One of those CPU instructions (or one class of them anyway) is called a jump. It allows you to move to a different instruction than the next one, including going backwards. There has always been reusability of already written code in digital computers. LOC was no more or less meaningful when code was written in assembly or machine language than it is today. It only measures something loosely correlated with progress toward completion and only if you know what done looks like.

gjkood 3y ago

Early in my career I once optimized an inherited 10,000+ line C program to less than 500 lines. It was a C program making SQL calls into a Sybase database. No, not because I had some brilliant insight but for the simple assumption that my predecessor may not have been aware of how to write functions or use parameters to supply variable data to the SQL query. They had literally written the same SQL statement inline with a couple of changed values in each SQL call. I just rewrote the code making the SQL call as a function call with bind variables as parameters into the function. All the replicated inline code was replaced with the function being called in a loop with the changed bind values supplied from an array.

papichulo2023 3y ago
Yooo, no params == no injection /s
deleted 3y ago
[deleted]
walth 3y ago
https://www.folklore.org/Discovered_Loops.html?sort=date?sort=date https://www.folklore.org/Discovered_Loops.html?sort=date?sor...

mig39 3y ago

Was this the original TPS report?

varjag 3y ago

It was a great write up in its time but has since become a goto cliche for people who can't write much code.

sandspar 3y ago
Article: "Did you know that geniuses like Einstein tend to be night owls?" Unemployed guy who wakes up at 11 a.m. every day: "I must be a genius!" Barba non facit philosophum: a beard doesn't make one a philosopher.
- TRiG_Ireland 3y ago
  > But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown. ― Carl Sagan

torginus 3y ago

I never understood why is it when people talk about LoC of code written, they always use 'lines added - lines removed'. If I do a run 10km run and end up in the same place I started, it's not a 0km run.

vacuity 3y ago
I think a part of it is that dumb diff tools may record large diffs when the change in functionality is limited and the rest is more or less moving lines around. Like making if cond { ... return; } ... into if cond { ... return; } else { .... } But that's not comprehensive either.

cromulent 3y ago

It’s the wrong metric. We all know that. It’s like measuring a manager by “meetings attended” or something like that. The hard part is measuring the effectiveness of people whose output is realized in the future, not today.