Comment by lmm | Hacker News Reader

Comment by lmm | Hacker News Reader

Parent Full thread

> 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.

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.

> 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.

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.

You're talking about a couple of general, powerful features, which is exactly the kind of thing that doesn't take 5 million lines of code to implement. Collaborative editing is definitely worthwhile. Integrating a scripting language is probably worthwhile. The only way you get to a huge ball of mud codebase (other than by being bad at programming) is by having lots of things that really are isolated special cases like, IDK, one more obscure statistical distribution that you can sample from, or one more date format, or one more connector integration.

Do important general features start out looking like this kind of esoteric edge case? I don't think so, though I'm not hugely confident. I think it should've been clear in 2005 that enabling collaborative editing would have been a fundamental shift that required reworking the core of Excel, not something that a single internal team could add as a checkbox feature. I think that's probably part of why it didn't happen.

There's definitely some business value from "supports everything", and in a messy human world that can be very complex - just things like knowing the business day calendar for every country take space in code, and if you're writing a piece of software that commits to integrating with everything else then the number of integrations you have to write is more a function of politics than of engineering. But I think that part is very much on the long tail, the "last 20%".

To answer the specific question, yes, I do think Excel 2000 is as good as Excel today is. I honestly can't think of a single positive new feature (automatically suggesting tables seems cool, but I don't trust it), and the changes I did notice are mainly the ones that got in my way like the "ribbon" menu. I'm sure some businesses are getting some extra value out of today's Excel, but only in long-tail stuff.

I don't blame people for working on the long-tail things, I've done plenty of it myself. It pays the bills, it can even be good engineering. But I don't think the article is right to imply that it's where most of the business value comes from.

Everyone wants to be a greenfield developer - even if they don't realize they are in a brown field.

Reply on news.ycombinator.com