One of the most important messages of the book has to do with conceptual integrity. The author is convinced that it is the main characteristic of a good product. Without it, software becomes incoherent and disorganized, or in other words not easy to use (which is the main goal of any software).

To achieve conceptual integrity, we need to adopt the approach of other industries, e.g. architecture. There should ideally be just one person responsible for designing the software. They may have a small team, but it should be up to the leader to decide what should the main pieces look like and how they will interact. Thankfully, the architect is not the only one with agency and impact. The implementation and module-level design is up to the guys who write code, which allows for creativity to be encouraged and nourished.

The author also argues that software development is inherently complex. We can take two paths when trying to improve the process of creating software. First, we can remove "accidental difficulties", for example by going from low-level language to a high-level one. To me, this is akin to using a power tool instead of a simple screwdriver - it's much faster, but the nature of the work remains the same.

What's hard to improve is the "essential difficulties" of writing software. Essential difficulties means figuring out what problems need to be solved, understanding all of the use-cases that need to be accounted for, and finally deciding on exactly what needs to be done. Because of that, the author doubts that there will ever be a manifold increase in productivity.

This still stands true today. Understanding what problems customers need solved is our biggest task as software developers. Writing code is just how we get from point A to point B. As we move towards AI-generated code and an even higher level of software design, it would still be necessary to translate vague and incomplete requirements into a complete working system.

It's also surprising how in 1975 there was already an understanding that waterfall fails to satisfy the needs of our process. Author mentions iterative development as a much better remedy, and it is fascinating how even today, in 2024, businesses need to be convinced that waterfall will not yield the desired results.