Review

Robert C. Martin
Pearson, 2018

I think this book is best understood by working backwards, starting from Appendix A. That appendix, entitled "Architecture Archaeology", is an entertaining romp through Martin’s career. Starting in the late 1960s, he describes a series of jobs developing various software systems. And not the easy way we do it now, when the computers come with an operating system. No, he started back when the computer was just the computer. Writing the operating system was left to the purchaser.

In the mid-1970s, he found himself working on a system that used Erasable Programmable Read-Only Memory (EPROM) chips to distribute software. That is, the software the machine ran wasn’t distributed via a "removable media", such as magnetic tape, which would have been appropriate for the era. Instead, it was recorded on a set of 30 EPROM chips per machine. The chips were physically distributed to each computer running the software and plugged into its board. I suppose the closest analogy is video game cartridges but imagine that your console had 30 cartridge slots.

I mention this anecdote because that experience taught Martin the importance of deployment boundaries. At first, they simply stored the program linearly, beginning to end, from the first chip to the last. Thus, any update, no matter how small, could change what was stored on each chip. An update to any part of the software required programming and shipping 30 chips—​per machine. That was clearly unsustainable, and the system was redesigned such that chips could be independently deployed. This required, in effect, thinking of each chip as a deployment unit—​something akin to a shared library, physically manifested.

The rest of the book contains 300 pages of a false equivalence between deployment boundaries and software architecture. To borrow from the 4+1 View Model, that’s like asserting that only the development view of a system matters. The development view is, of course, an architectural consideration. In some systems, I suppose it might be "dominant" in the sense that it has the biggest impact on outcomes and maintenance. But to assert that the logical, process, and physical views are not part of architecture seems wholly unreasonable.

For example, Chapter 30, "The Database is a Detail", begins with this wild assertion that "[f]rom an architectural point of view, the database is a non-entity—​it is a detail that does not rise to the level of an architectural element." The point that Martin is trying to make is that one shouldn’t create a strong coupling between their system and any given database implementation. OK, fine. But to assert that architects can ignore the database? Different database implementations have different performance characteristics and deployment options. They have different capabilities with respect to reliability and recovery. Any architect concerned with dependability must understand the operational characteristics of their database and design accordingly. And every architect should be concerned about dependability. There’s simply no justification for this statement if working from any reasonable industry definition of "software architecture."

Martin has, I think, committed the error of working solely from his own experience, rather than broadening his viewpoint by considering a wider software-industry lens. Perhaps nothing makes this clearer than his comment in Chapter 15, "What is Architecture," that Software architects are the best programmers." Speaking from personal experience, I know this is not the case. I’m a decent programmer, but I’ve worked with many who were better. Most of them are not architects because architecture requires a different skillset. To conflate the two is to demonstrate a basic failure to grasp software architecture as a discrete discipline within the broader realm of software engineering.

Which brings me to my other major objection to this book: The "clean architecture" that it advocates is not much of an architecture. One the one hand, it imposes a strict layering of concerns. On the other hand, it has nothing to say beyond the layering. It’s not a bad pattern for the many "line of business" applications that have this general form. But many systems aren’t line of business applications. And even within line of business applications, there are many interesting questions to answer about relationships within each layer.

For anyone working on line of business applications, Righting Software is a better read. Like Martin, Lowy is perhaps not clear enough about the types of software to which his approach does and does not apply. But his focus on "volatility-based decomposition" is spot-on, and it tackles the difficult parts of structuring a line of business application that Martin largely ignores. Ultimately, this is a book about programming, mis-labeled as one on architecture.