5 ms·

One of the key quotes: > Another important reason for software complexity lies in monolithic design, wherein all conceivable features are part of the system's d

One of the key quotes: > Another important reason for software complexity lies in monolithic design, wherein all conceivable features are part of the system's design. Each customer pays for all features but actually uses very few. Ideally, only a basic system with essential facilities would be offered, a system that would lend itself to various extensions. Every customer could then select the extensions genuinely required fora given task.

sidlls 5y ago
Such a system sounds nice in theory. In practice it leads to a byzantine nightmare of configurable interfaces, support systems, and so on, with a result that is ultimately fatter and harder to maintain.
- CraigJPerry 5y ago
  I disagree with that - what i’d call a plugin architecture - leads to a very nice separation of components.
  - interactivecode 5y ago
    plugins works for things that are plugins. Most people seem to equate separation of concerns with everything should be a plugin. Otherwise you get massive issues actually working across each plugin (or package). So unless your component is actually used in multiple core products it's not a component, it's just a part of your monolith. Making it a separate component usually, just spreads your monolith across several git repo's
- Jtsummers 5y ago
  I don’t know. It sounds similar to a lot of IDEs. Produce an interface that plugins can make use of, then people can extend the system to support new languages and capabilities. Seems to work well in a lot of cases.
- mysterydip 5y ago
  That was my first reaction, but I think it can work in some cases. Take for example plugins in a paint program, or dissectors in wireshark. Both of those can have any number of user-created extensions for different packet types or editing that the general populace doesn't need. However, to your point, when wireshark changes their API every few versions, all the plugins have to change as well or you either break your dissectors or are stuck on an old version. The base program should be designed with extension maintainability in mind.
- jcelerier 5y ago
  As an user, all the software that I take actual pleasure in using and make me productive, are large plug-in based software. As a developer of a mainly plug-in based application, the iterating ability it gives is pretty incredible - nowadays for a large majority of my feature requests, I don't have to touch the original codebase at all, just create a small plug-in for the feature.
- vendiddy 5y ago
  If the interfaces are defined poorly, it can result in what you are describing. But I've seen systems do this well and the result is something far less complex. I agree with the author's view that good interfaces require iteration. So expect that several irrational will have incorrectly drawn boundaries and poorly defined interfaces. This kind of design takes time, but if you expect the system but if you expect that it will need to evolve over the years, it pays for itself.
- 7952 5y ago
  Well it depends on the level of abstraction you use. You could think of the operating system as the platform, and each piece of software as a plugin. That can work well enough. I can save a PNG in photoshop, and then open it in other programs and it just works. But the file paradigm has lost popularity and there are probably some good reasons for that.
- fouric 5y ago
  Emacs is a system that adheres to this theory, being a small C core that implements an elisp runtime, and then the rest of the built-in functionality (as well as the entire plugin ecosystem) implemented as easily-tweakable elisp on top of that - but has not turned into "a byzantine nightmare of configurable interfaces, support systems, and so on". It's quite the counterexample to this claim.
  - taeric 5y ago
    I'd argue that emacs is more monolithic in is main focus of text editing and elisp execution. It doesn't just build a plugin architecture. It literally built a platform and does most of it's work in the same way that user code can run.
necrotic_comp 5y ago
Isn't this more or less the idea behind Gentoo ? I know that when I initially started setting my system up, it was a bit of a mess trying to figure out what USE flags I needed/etc., but once it stabilized, it was great to know that I had a system that worked and there was no trace of software or libraries I didn't want or need. It definitely is a bit more legwork to do up-front, but I feel like the idea of "this is what I want, please build only to that spec" has saved me a bit of heartache as I've been using my system and while the leanness doesn't matter per se, it feels like it's helping my system be a bit more organized.

sidlls 5y ago

Such a system sounds nice in theory. In practice it leads to a byzantine nightmare of configurable interfaces, support systems, and so on, with a result that is ultimately fatter and harder to maintain.

CraigJPerry 5y ago
I disagree with that - what i’d call a plugin architecture - leads to a very nice separation of components.
- interactivecode 5y ago
  plugins works for things that are plugins. Most people seem to equate separation of concerns with everything should be a plugin. Otherwise you get massive issues actually working across each plugin (or package). So unless your component is actually used in multiple core products it's not a component, it's just a part of your monolith. Making it a separate component usually, just spreads your monolith across several git repo's
Jtsummers 5y ago
I don’t know. It sounds similar to a lot of IDEs. Produce an interface that plugins can make use of, then people can extend the system to support new languages and capabilities. Seems to work well in a lot of cases.
mysterydip 5y ago
That was my first reaction, but I think it can work in some cases. Take for example plugins in a paint program, or dissectors in wireshark. Both of those can have any number of user-created extensions for different packet types or editing that the general populace doesn't need. However, to your point, when wireshark changes their API every few versions, all the plugins have to change as well or you either break your dissectors or are stuck on an old version. The base program should be designed with extension maintainability in mind.
jcelerier 5y ago
As an user, all the software that I take actual pleasure in using and make me productive, are large plug-in based software. As a developer of a mainly plug-in based application, the iterating ability it gives is pretty incredible - nowadays for a large majority of my feature requests, I don't have to touch the original codebase at all, just create a small plug-in for the feature.
vendiddy 5y ago
If the interfaces are defined poorly, it can result in what you are describing. But I've seen systems do this well and the result is something far less complex. I agree with the author's view that good interfaces require iteration. So expect that several irrational will have incorrectly drawn boundaries and poorly defined interfaces. This kind of design takes time, but if you expect the system but if you expect that it will need to evolve over the years, it pays for itself.
7952 5y ago
Well it depends on the level of abstraction you use. You could think of the operating system as the platform, and each piece of software as a plugin. That can work well enough. I can save a PNG in photoshop, and then open it in other programs and it just works. But the file paradigm has lost popularity and there are probably some good reasons for that.
fouric 5y ago
Emacs is a system that adheres to this theory, being a small C core that implements an elisp runtime, and then the rest of the built-in functionality (as well as the entire plugin ecosystem) implemented as easily-tweakable elisp on top of that - but has not turned into "a byzantine nightmare of configurable interfaces, support systems, and so on". It's quite the counterexample to this claim.
- taeric 5y ago
  I'd argue that emacs is more monolithic in is main focus of text editing and elisp execution. It doesn't just build a plugin architecture. It literally built a platform and does most of it's work in the same way that user code can run.

necrotic_comp 5y ago

Isn't this more or less the idea behind Gentoo ? I know that when I initially started setting my system up, it was a bit of a mess trying to figure out what USE flags I needed/etc., but once it stabilized, it was great to know that I had a system that worked and there was no trace of software or libraries I didn't want or need. It definitely is a bit more legwork to do up-front, but I feel like the idea of "this is what I want, please build only to that spec" has saved me a bit of heartache as I've been using my system and while the leanness doesn't matter per se, it feels like it's helping my system be a bit more organized.