> The ideal is to build powerful systems from small, simple processes
That's only half of the story, because now the complexity lies in orchestrating those processes.
Let's stay at the example of build systems. These are usually a serial execution of simple processes, so they make up a "best case" scenario. Yet, build systems quickly reach a uncomfortable complexity. See Autotools, CMake, and so on. It is kind of ongoing research: Every few years we find better ways to orchestrate a build system. As of today, there is no build system which is 1) simple and easily comprehensible, 2) reliable and rock stable and 3) still able to build complex applications with all their (seemingly) quirky needs.
It's not only about having simple processes, but also about splitting the complex problem in an intelligent way, so the simple processes have simple interfaces and simple (and few!) interactions. Otherwise, the orchestrating itself becomes the main application, and may easily become even more complex than a monolithic approach would have been.
That's only half of the story, because now the complexity lies in orchestrating those processes.
Let's stay at the example of build systems. These are usually a serial execution of simple processes, so they make up a "best case" scenario. Yet, build systems quickly reach a uncomfortable complexity. See Autotools, CMake, and so on. It is kind of ongoing research: Every few years we find better ways to orchestrate a build system. As of today, there is no build system which is 1) simple and easily comprehensible, 2) reliable and rock stable and 3) still able to build complex applications with all their (seemingly) quirky needs.
It's not only about having simple processes, but also about splitting the complex problem in an intelligent way, so the simple processes have simple interfaces and simple (and few!) interactions. Otherwise, the orchestrating itself becomes the main application, and may easily become even more complex than a monolithic approach would have been.