In the stated examples there's are no benefits to the additional complexity. No one would argue that complexity for the sake of it is a good idea. That'd be insane. If Alice's restaurant could handle 5,000,000 covers a night with only 1 member of staff while Zola's restaurant could only handle 10,000 then you'd have a more realistic scenario to compare with the SaaS industry. The benefit of "complexity" is that you are able to do more things with less work.

The ideal is to build powerful systems from small, simple processes - if any single stage is trivial then anyone can understand it, fix it, modify it, and so on. With many little processes working together you can do amazing things. A good example in software is a build process - a good system can lint code, test it, uglify it, minify it, push it to version control, watch for changes, reload an output mechanism, clean up a distribution, and push it to a live server if it's working all from a single command. That's very 'complex', but really it's just a set of very simple linked processes.

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

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.

See https://github.com/gyepisam/redux

It's an implementation of DJB's redo concept.

I wrote it because I needed a build tool with exactly the features you describe\nand none of the alternatives had them.

I encourage you to try it out and provide feedback if necessary.

https://github.com/apenwarr/redo

It might be interesting to see if the two of you interpreted DJB's documentation in the same ways.