And the rest of the book deals with why it is more often than not painful. In summary, it's complexity. Brooks argues that software, being a pure thought-stuff, is also the most complex thing we attempt to build. And it's even worse now than in his time with any concern for quality taking a back seat in the face of competitive pressures. So it's not really surprising that slapping together ever more complex systems out of ill-fitting, purely-designed components is not fun.
After taking a break from software side-projects to work on more physical things (woodworking, metal-working, welding). I have to agree that software is one of the most complex things we work on. Even something quite complicated that's evolved over decades, like a car, is largely comprehensible to a single person without an enormous amount of effort (i.e. many people understand how every single subsystem of a car works), while understanding everything in say linux or postgres takes a much higher level of effort (it can be done too, but there is a lot more complexity to keep track of).
It's so weird to me that software's complexity is such a force of nature.
My instinct is that no implementation of a piece of software should ever need to be more complex than the idea of it is (fully and precisely articulated, of course). Yet the code is usually orders of magnitude more complex than that. I don't understand why we can't solve this problem.
The paper "Out of the tar pit" (https://github.com/papers-we-love/papers-we-love/blob/master...) discusses this in more details. Basically it argues that one needs to separate the complexity into essential complexity (complexity inherent to the problem) and accidental complexity (complexity due to the way the solution is designed). The idea is to reduce accidental complexity as much as possible while making the essential complexity more managegable.
The paper also discusses that you can separate a program into
1. state (data that changes over time)
2. behavior (computational logic)
In order to reduce the accidental complexity, you can use functional programming (which is purely behavior, devoid of complexity due to state mutation) for the behavior part. For the state part, you can use a relational database to manage it in a more systematic manner. They call it functional-relational approach to software design.
If you do game development, you likely heard of ECS (entity-component-system) and data oriented programming which in a way promotes this approach to software design.
