While some small, simple programs are great, big economic contribution is mainly in large software: manufacturing control, ERP, air-traffic control, power-plant control etc.. Small software is great, but the big economic impact belongs to big software.
There is no reason why 'big software' can not be made up out of small software pieces inter-operating. In fact those are the strongest and most maintainable systems.
Small software that's made up of small pieces is still big software. In fact, most big software systems in the last twenty years or so are built that way, but that doesn't eliminate the the complexity. It makes it manageable -- not cheap.
Big software is made up of inter-operating small pieces of software: subroutines and objects ;)
Breaking something into multiple processes doesn't magically reduce complexity. You can have the same architecture within one process or spread out among 50, and in the latter case you've actually added the complexity of some IPC layer and lifetime management for all of the different processes.
That's obviously not what you meant to say. You meant: break things down into the right abstract components such as to decrease coupling and increase cohesion. You meant: do it so well that Component A can be maintained by a team that doesn't even know about the existence of Component B. And that routine changes in the requirements for one don't require changes in the other. That's really hard, especially if your codebase is a coupled mess because you wanted to SHIP IT fast. It's very hard to make a business case for big refactoring ("So we're going to spend all of this money and at the end it's going to work the same way it does now, but maybe a bit better? Can't we just spend that money fixing bugs instead?"). Also, strong boundaries between components can ironically make it harder to refactor, when it turns out that a different breakdown makes more sense. And God-forbid that other projects have taken dependencies on the components, further tying your hands.
If this was like traditional engineering, you'd have some massive upfront planning effort, dozens of committees, reviews by regulators, massive fault tolerance, etc. You'd then have a (hopefully) mini version of this same process every time requirements change or technical limitations get in the way of your original plan. Five years later you release your shiny piece of modular enterprise software. But your competitor shipped their big monolithic alternative that GetsTheJobDone in a quarter of the time and price. A good example of this is that all of the successful operating systems have monolithic kernels, even though academics and researchers favor microkernels.
So you're right, there's no reason why big software can't be made up of a bunch of small software, but there are a lot of reasons why it sometimes isn't.
> Breaking something into multiple processes doesn't magically reduce complexity.
Actually, it does.
If you break up a complex system into communicating processes then for each and every process you have a clearly defined set of inputs and outputs, memory protection, the ability to run multiple instances seamlessly without mucking around with threads and a very much reduced scope.
Decomposition into multiple communicating processes is an extremely powerful tool to reduce complexity.
Yes, it reduces complexity considerably, but nearly all big systems are already built this way and are still very complex. You cannot use this approach to eliminate complexity, i.e. make the cost linear with the system size.
Some domains where software is used to yield a tremendous economic impact are so complex that even with all complexity-management approaches at our disposal, the cost of creating them still grows super-linearly with their size.
If there are n abstract features to the system, all dependent on almost all others, you have an order of n^2 interactions. Whether you make every function its own simple communicating process, or bundle a few of them together (shifting complexity into a process) the abstract complexity of the system is still n^2.
Yes, it reduces complexity considerably, but nearly all big systems are already built this way and are still very complex.
complexity is a function of interactions. multiple processes won't do much for you if every one communicates with everybody else.
If there are n abstract features to the system, all dependent on almost all others [...].
the discussion has been about using process separation as an aid in preventing accidental complexity arising from improper coupling introduced as a shortcut so this looks a little disingenuous. my response is that if you separate every function into its own simple process, a misbehaving function need not take down the whole group.
on the improper-coupling-reduction front, process separation is apparently paramount to success, see eg. sendmail vs postfix.
Let me put it another way. Many of the software systems that make the biggest economic contributions have a very high essential complexity, and so their cost grows super-linearly with their size.
That's true, but if you architect it well you should still be able to have an overview with every program as a functional block and inside the programs the scope should be limited enough that they are easy to understand. It's all a matter of balance. Good examples of such systems: message switches, telephone installations, routers, large scale web applications and so on. These are all very suitable to such decomposition into communicating processes.
Sure, but I think the author's point about "diseconomy" of scale still stands even when the large system is composed of small parts (and pretty much all large software systems in at least the last 20 years have been composed of small parts).
You could make the exact same claim about any bespoke piece of technology. What does it cost to make one new car? one aircraft? one piece of electronics? one moon rocket? one satellite?
It's all economies of scale that come into play as soon as you can ramp up the volume. And that's where software wins hands down, in spite of all the up-front costs.
