4 ms·

> No-one's actual business problem takes 5M lines of code to describe, those 5M lines are mostly copy-paste "patterns" and repeated attempts to reimplement the

by edanm 2y ago

> No-one's actual business problem takes 5M lines of code to describe, those 5M lines are mostly copy-paste "patterns" and repeated attempts to reimplement the same thing. I'm pretty sure this is trivially untrue. Any OS is probably more than 5M lines (Linux - 27.8 lines according to a random Google Search). Facebook is probably more lines of code. Etc.

lmm 2y ago
> Any OS is probably more than 5M lines (Linux - 27.8 lines according to a random Google Search). Linux is notoriously fragmented/duplicative, and an OS isn't the solution to anyone's actual business problem. A well-factored solution to a specific problem would be much smaller, compare e.g. QNX. > Facebook is probably more lines of code. IIRC Facebook is the last non-monorepo holdout among the giants, they genuinely split up their codebase and have parts that operate independently. Does Facebook have more than 5M lines of code now? I'm sure they do. Does that actually result in a better product than when it was less than 5M lines of code? Ehhhh. Certainly if we're talking about where the revenue is being generated, as the article wants to, then I suspect at least 80% of it is generated by the <5M that were written first. So I mean yeah, on some level solving the business problem can take as many lines as you want it to, because it's always possible to add some special case enhancement for some edge case that takes more lines. But if you just keep growing the codebase until it's unprofitable then that's not actually particularly valuable code and it's not very nice to work on either.
- edanm 2y ago
  I'm fairly sure Word, Excel, Google Sheets, Youtube, Photoshop, etc. all have fairly high counts. As do many tens of thousands of applications that are the backbone of services we all rely on. The systems that run banks, that run power plants, the routers that make up the backbone of the internet, etc. Again, I agree with some of the spirit of what you're saying... but there's also a tendency of many developers (like myself) to only think of shiny new products, or to only think about the surface-level details of most business problems. You write: > So I mean yeah, on some level solving the business problem can take as many lines as you want it to, because it's always possible to add some special case enhancement for some edge case that takes more lines. But if you just keep growing the codebase until it's unprofitable then that's not actually particularly valuable code and it's not very nice to work on either. I think this misunderstands how the companies that have stayed in business for so long have done so. Excel is the software we all use every day because it kept adding more and more features, stealing the best ideas from new products that tried to innovate. It's still doing so, though obviously to a lesser extent.
  - lmm 2y ago
    > I think this misunderstands how the companies that have stayed in business for so long have done so. Excel is the software we all use every day because it kept adding more and more features, stealing the best ideas from new products that tried to innovate. Not convinced. I think a lot of companies keep adding features because they don't know how to do anything else - adding new features is how managers get promoted, so it's what devs get rewarded for, so it keeps happening even as the RoI drops lower and lower (and in many cases eventually goes negative - but this is masked because the core idea was good enough then the product as a whole is still profitable). At "best" a bunch of esoteric features act as a de facto moat that can shut out the competition in a tickbox-feature-comparison, rather than being something that's actually adding value in day-to-day use.
    - edanm 2y ago
      Yes, I understand the sentiment and am familiar with this argument. And sometimes it's totally true! But I'm pushing back because I think it's sometimes not true, and that this is more an "anti-growth" or "here's-how-real-devs-work" talking point that is sometimes applied incorrectly. E.g. how far are you taking this? Excel was released in 1985. Do you think after 5 years there was no more business value? VBA, allowing scripting, wasn't released until 1993. Do you think think Excel circa 2000 is as good as Excel today is? I'm sure it's roughly similar, but I'm just as sure there are many features that I would miss. And that's not even getting to the fact that Excel lost a ton of marketshare to Google Sheets, because it was too late to adopt what is Sheet's biggest feature - collaborative editing. I'm sure in 2005 you could've made the case that Excel already has all the business value it needs, and trying to add something like collaborative editing is just a corporate waste of time, a totally "esoteric" feature that no one really needs and doesn't provide value, and is only there to get managers promoted or to get devs working on something "cool". Yet arguably it was a critical thing they needed to get done and didn't. Anyway, I'm sure you're right a lot of the time. I just think blankly applying this statement is very wrong, when real people in the real world are sometimes working on systems, 10, 20 or sometimes even 50 years old.
      - 2y ago

by edanm 2y ago

lmm 2y ago

> Any OS is probably more than 5M lines (Linux - 27.8 lines according to a random Google Search). Linux is notoriously fragmented/duplicative, and an OS isn't the solution to anyone's actual business problem. A well-factored solution to a specific problem would be much smaller, compare e.g. QNX. > Facebook is probably more lines of code. IIRC Facebook is the last non-monorepo holdout among the giants, they genuinely split up their codebase and have parts that operate independently. Does Facebook have more than 5M lines of code now? I'm sure they do. Does that actually result in a better product than when it was less than 5M lines of code? Ehhhh. Certainly if we're talking about where the revenue is being generated, as the article wants to, then I suspect at least 80% of it is generated by the <5M that were written first. So I mean yeah, on some level solving the business problem can take as many lines as you want it to, because it's always possible to add some special case enhancement for some edge case that takes more lines. But if you just keep growing the codebase until it's unprofitable then that's not actually particularly valuable code and it's not very nice to work on either.

edanm 2y ago
I'm fairly sure Word, Excel, Google Sheets, Youtube, Photoshop, etc. all have fairly high counts. As do many tens of thousands of applications that are the backbone of services we all rely on. The systems that run banks, that run power plants, the routers that make up the backbone of the internet, etc. Again, I agree with some of the spirit of what you're saying... but there's also a tendency of many developers (like myself) to only think of shiny new products, or to only think about the surface-level details of most business problems. You write: > So I mean yeah, on some level solving the business problem can take as many lines as you want it to, because it's always possible to add some special case enhancement for some edge case that takes more lines. But if you just keep growing the codebase until it's unprofitable then that's not actually particularly valuable code and it's not very nice to work on either. I think this misunderstands how the companies that have stayed in business for so long have done so. Excel is the software we all use every day because it kept adding more and more features, stealing the best ideas from new products that tried to innovate. It's still doing so, though obviously to a lesser extent.
- lmm 2y ago
  > I think this misunderstands how the companies that have stayed in business for so long have done so. Excel is the software we all use every day because it kept adding more and more features, stealing the best ideas from new products that tried to innovate. Not convinced. I think a lot of companies keep adding features because they don't know how to do anything else - adding new features is how managers get promoted, so it's what devs get rewarded for, so it keeps happening even as the RoI drops lower and lower (and in many cases eventually goes negative - but this is masked because the core idea was good enough then the product as a whole is still profitable). At "best" a bunch of esoteric features act as a de facto moat that can shut out the competition in a tickbox-feature-comparison, rather than being something that's actually adding value in day-to-day use.
  - edanm 2y ago
    Yes, I understand the sentiment and am familiar with this argument. And sometimes it's totally true! But I'm pushing back because I think it's sometimes not true, and that this is more an "anti-growth" or "here's-how-real-devs-work" talking point that is sometimes applied incorrectly. E.g. how far are you taking this? Excel was released in 1985. Do you think after 5 years there was no more business value? VBA, allowing scripting, wasn't released until 1993. Do you think think Excel circa 2000 is as good as Excel today is? I'm sure it's roughly similar, but I'm just as sure there are many features that I would miss. And that's not even getting to the fact that Excel lost a ton of marketshare to Google Sheets, because it was too late to adopt what is Sheet's biggest feature - collaborative editing. I'm sure in 2005 you could've made the case that Excel already has all the business value it needs, and trying to add something like collaborative editing is just a corporate waste of time, a totally "esoteric" feature that no one really needs and doesn't provide value, and is only there to get managers promoted or to get devs working on something "cool". Yet arguably it was a critical thing they needed to get done and didn't. Anyway, I'm sure you're right a lot of the time. I just think blankly applying this statement is very wrong, when real people in the real world are sometimes working on systems, 10, 20 or sometimes even 50 years old.
    - 2y ago