A classic book written by "Uncle Bob". As the title says: "A Craftsman's Guide to Software Structure and Design."

Case Study and "The Signature of a Mess"

I appreciate the book starting off spelling out why clean architecture is so important, and used case studies to highlight it. To summarize: He demonstrated how costly each line of code got with each release. He concludes with the following taken directly from the book (p. 7):

THE SIGNATURE OF A MESS

What you are looking at is the signature of a mess. When systems are thrown together in a hurry, when the sheer number of programmers is the sole driver of output, and when little or no thought is given to the cleanliness of the code or the structure of the design, then you can bank on riding this curve to its ugly end.

Figure 1.4 shows what this curve looks like to the developers. They started out at nearly 100% productivity, but with each release their productivity declined. By the fourth release, it was clear that their productivity was going to bottom out in an asymptotic approach to zero.

I have seen this very thing myself. Early in projects there's great incentive to get something out the door and demonstrate productivity. I've heard promises of "We'll go back and clean it up later."

"Later" no time is allotted to clean up the code. As a result, productivity slows down due to us know working with fragile code.

After some similar to discussion, and relation to the famous story of the "Tortoise and the Hare" Martin concludes with the following excellent quote on p.11:

The only way to go fast, is to go well

Later he has an excellent discussion on the value of code that is "easy to change" over code that "currently works perfectly". Since all applications change over time, this is very insightful!

Fight for the Architecture

Page 18 has a section title "Fight for the Architecture". It discusses the struggle between all the players: Management, marketing, sales, developers. Regarding this struggle, Martin says the following:

Effective software development teams tackle that struggle head on. They unabashedly squabble with all the other stakeholders as equals. Remember, as a software developer, you are a stakeholder. You have a stake in the software that you need to safeguard. That's part of your role, and part of your duty. And it's a big part of why you were hired.
[emphasis mine]

Excellent point!

The very next chapter begins his thesis. However I have to say that chapter I alone was worth the cost of this book!