4 ms·

As a disclaimer, I wasn't intending to bait anyone. I'm genuinely interested if there are any reasons for writing a 100k+ LOC application, rather than dividing

As a disclaimer, I wasn't intending to bait anyone. I'm genuinely interested if there are any reasons for writing a 100k+ LOC application, rather than dividing the functionality up between smaller applications and libraries. Operating systems like the Linux kernel are usually over 100k LOC, but Linus has made some compelling arguments about why you'd want a monolithic architecture in an operating system you want to be reasonably performant. But that argument doesn't appear to apply to server systems running under the JVM. Building an application out of small, interchangeable, independent components seems rather more sensible than one large monolithic architecture. My current hypothesis is that any server application over, say, 10K LOC is badly designed. I'm therefore quite interested in anyone who maintains or develops very large server systems, and if they could perhaps offer any reasoning why systems that large are the best solution. Admittedly this is a little off-topic, though :)

JoachimSchipper 15y ago
Data point: nginx-1.0.14 has 124 574 lines in the src/ directory.
ExpiredLink 15y ago
> I'm genuinely interested if there are any reasons for writing a 100k+ LOC application, rather than dividing the functionality up between smaller applications and libraries. IIRC, Google has such 'large' settings (for whatever reason). All companies I've seen use the latter approach.
skybrian 15y ago
Well-designed large apps actually are divided up into smaller components - there'd be no way to maintain them otherwise. However, it doesn't help as much as you'd think. If it's a layered architecture, sometimes adding new feature means you have to modify code in every layer. And dividing code up into libraries doesn't help build times when you need to modify a base library that everything uses. If you have trouble imagining this, pretend that every dependency you use is actually part of your code base, and sometimes you have to modify them because they're not completely baked. If you have non-trivial functionality, you are certainly using way more than 100k LOC.
- weavejester 15y ago
  I'm afraid I still can't imagine a large system that could not conceivably be divided into small, independent components. You mention dependencies that are "not completely baked", but isn't that just another way of saying "bad design"?
  - batista 15y ago
    I'm afraid I still can't imagine a large system that could not conceivably be divided into small, independent components. Well, examine some large systems then, and see whether you can fare better. Depends on what you describe as independent components. The 200LOC thing is probably also comprised of independent components. As in NGINX that somebody mentions elsewhere. That doesn't mean those independent components don't have to work together and a change in one doesn't affect the other. Consider a plugin host and a plugin. They are independent, alright, but the plugin takes advantage of certain things the host offers. If you change the host in those areas, you'll have to change the plugins too. Components only provide independency until the place where they meet each other, i.e. the "joins". (Even in a functional language, a pure function only provides independency until the point you call it --there you have to adhere to its interface).
    - weavejester 15y ago
      Well, examine some large systems then, and see whether you can fare better. Examining very large codebases takes time, so this is easier said than done! I have worked with several large projects, but all of them would have been better factored out into smaller services. Components only provide independency until the place where they meet each other, i.e. the "joins". I don't think that's true. Two components can share the same contract, but still not be dependent on one another. For example, the Unix applications "wc" and "grep" have no dependency on one another, but they can be piped together because they share the same STDIN/STDOUT interface. Similarly, the functions "+" and "*" can be used together because they have compatible type signatures, but this does not mean they are not independent.
      - 15y ago

JoachimSchipper 15y ago

Data point: nginx-1.0.14 has 124 574 lines in the src/ directory.

ExpiredLink 15y ago

> I'm genuinely interested if there are any reasons for writing a 100k+ LOC application, rather than dividing the functionality up between smaller applications and libraries. IIRC, Google has such 'large' settings (for whatever reason). All companies I've seen use the latter approach.

skybrian 15y ago

Well-designed large apps actually are divided up into smaller components - there'd be no way to maintain them otherwise. However, it doesn't help as much as you'd think. If it's a layered architecture, sometimes adding new feature means you have to modify code in every layer. And dividing code up into libraries doesn't help build times when you need to modify a base library that everything uses. If you have trouble imagining this, pretend that every dependency you use is actually part of your code base, and sometimes you have to modify them because they're not completely baked. If you have non-trivial functionality, you are certainly using way more than 100k LOC.

weavejester 15y ago
I'm afraid I still can't imagine a large system that could not conceivably be divided into small, independent components. You mention dependencies that are "not completely baked", but isn't that just another way of saying "bad design"?
- batista 15y ago
  I'm afraid I still can't imagine a large system that could not conceivably be divided into small, independent components. Well, examine some large systems then, and see whether you can fare better. Depends on what you describe as independent components. The 200LOC thing is probably also comprised of independent components. As in NGINX that somebody mentions elsewhere. That doesn't mean those independent components don't have to work together and a change in one doesn't affect the other. Consider a plugin host and a plugin. They are independent, alright, but the plugin takes advantage of certain things the host offers. If you change the host in those areas, you'll have to change the plugins too. Components only provide independency until the place where they meet each other, i.e. the "joins". (Even in a functional language, a pure function only provides independency until the point you call it --there you have to adhere to its interface).
  - weavejester 15y ago
    Well, examine some large systems then, and see whether you can fare better. Examining very large codebases takes time, so this is easier said than done! I have worked with several large projects, but all of them would have been better factored out into smaller services. Components only provide independency until the place where they meet each other, i.e. the "joins". I don't think that's true. Two components can share the same contract, but still not be dependent on one another. For example, the Unix applications "wc" and "grep" have no dependency on one another, but they can be piped together because they share the same STDIN/STDOUT interface. Similarly, the functions "+" and "*" can be used together because they have compatible type signatures, but this does not mean they are not independent.
    - 15y ago