Lucid Mesh

We must be careful to strike the right balance when coding so that we don't unnecessarily obscure things that should be simple and easy to understand just for the sake of abstraction. Sometimes it's better to lay out a process linearly so that it can all fit on the screen at the same time instead of slicing and dicing to the point where the poor sap who has to debug the code needs to chase the flow of execution through dozens of functions and variables across tens of files. This insight gets at one of the themes of the book on making code habitable:

Habitability is the characteristic of source code that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently.

This idea of habitability is a worthy goal, and Gabriel returns to it often in the context of Alexander's architecture patterns:

What Alexander seems to be saying is that if we try to use modular parts (solid building blocks not easily molded to the current circumstances), then the overall structure of the thing built with them may become overly constrained by their shape. In programming, if a set of large abstractions does nearly the right thing, it is tempting is [sic] to use them and to bend the structure of the surrounding program to fit them. This can lead to uninhabitable programs.

It seems like much of modern software development has become exactly this, where we as programmers have been reduced to searching for and slapping together all of the packages we need to meet the given software requirements. In this process of moving towards extreme reuse, something has been lost in software development, and this is speaking from a perspective more than twenty years after this book was written, with reuse being much more common and extensive than it was then. This thing that has been lost is Alexander's "quality without a name."

Both Alexander and Gabriel spent a lot of time trying to define this quality without a name, but neither succeeded very well. Gabriel critiqued Alexander's choices in descriptive words, like "simple" and "cohesive," but while he was right that the word choices did not do the concept justice, he did not do much better in clarifying what the quality was. Even more troublesome than defining it, Alexander found that he couldn't replicate this nameless quality by enumerating the patterns of architecture. It's not something that you can create simply by combining known good patterns in a building.

This difficulty of codifying quality is true for almost anything we do. It's as true for architecture as it is for programming as it is for every form of craftsmanship, and it seems obvious that this would be so. We can't package up and mass produce quality that simultaneously exhibits beauty, elegance, efficiency, and function. Reaching the point where you can produce things of such a high level of quality takes decades of experience, creativity and experimentation. Most people will never reach the level of craftsmanship where their work is elevated to an art form.

It was frustrating that Gabriel danced around that conclusion for most of the book, but never really committed to it. He did spend a fair amount of time on silly tangents, like the chapter where he claimed that the development of programming languages was at an end, and C was the ultimate answer. That prediction looks mighty short-sighted today.

The rest of the book, detailing Gabriel's struggles through college and running a software business, was sometimes interesting and sometimes not, but it didn't have much to do with the first half of the book on patterns and code habitability. In general, his writing was quite repetitive and disorganized. He would introduce a new topic or part of a story by giving away the conclusion as if it was a stand-alone statement, and then proceed into an extended discussion on it. A few pages later I would realize he was talking about the details of a story that I had thought was just an isolated observation and we had moved on. This writing style was quite disorienting, and the constant repetition of certain observations or narratives, each time stated as if it was the first, became fairly annoying.

Between the sparse real insights and disjointed structure of the book, I can't recommend Patterns of Software at all. The software development advice can easily be had in much better books without the extended and largely irrelevant fluff. It's unfortunate. I feel like I really struck out with this book and The New Turing Omnibus, but sometimes that happens. Maybe the next couple books I read will be much better.