Reading notes: Patterns of Software

I'll probably never finish Richard Gabriel's Patterns of Software: Tales from the Software Community. The core of the book (or at least the first 1/3 of it) is a meditation on the career of Christopher Alexander can teach us about software design.

Gabriel's turns of phrase tend not to land with me, partly because the technical discussion doesn't include examples or sufficiently precise argumentation about software. There are enough mechanical errors (at least in my edition) to distract the reader, and the structure of the book (a series of titled, related semi-essays) works against my attempts to synthesize the information.

But I'm glad this book exists. It reminds me of poker literature. When I studied poker most seriously, it was immature as a field of study, with an oral tradition of knowledge-transmission and enthusiastic practitioners. This led to a lot of technical and semi-technical writing that is unconstrained by traditional subgenre boundaries. Such projects don't always succeed or endure, but the practical alternative to this kind of artifact is usually not a polished, impeccably structured book but rather nothing at all.

So, in the case of Richard Gabriel, if someone loves software, loves architecture, and wants to write a long meditation on the connections between the ineffable qualities of great software and the career of Christopher Alexander, I really want that person to write that meditation. My life is better because Barry Greenstein wrote something that reminds me of Seneca more than anything else, Bob Ciaffone saw fit to publish occasionally speculative advice back in 1997--and because poker literature was unsaturated enough to have some room for my own self-published speculations. It's also better because I picked up this book. I just can't finish it.

Some notes:

1. Gabriel speaks of habitability in software design. Michael Feathers gives an related warning: "Remember, code is your house, and you have to live in it." Feathers is talking about hygiene where Gabriel is discussing something less tangible, and the continuity of the metaphor is striking. It has infiltrated my work: every day I think of myself as living in the software I work on.
2. Gabriel says that clarity "is just too rare, and it's dangerous too, in a funny way." This is nonobvious and correct (and I want to post it in every building where analytic philosophers work). Aristotle famously warns us to tailor the precision of our descriptions to the underlying subject matter: Don't settle for mere persuasion if you're discussing geometry, but also don't expect geometrical proof if you're talking about the weather. We want clarity in software, but only insofar as it's there to be achieved. Suppose an argument already has as much clarity as it's going to get. If you try to add more, something will go wrong: you'll think you're adding clarity but actually be adding something else, or you really will be adding clarity but about the wrong thing. Either way, the whole suffers. In software, this kind of misguided aim at clarity can lead to extra objects, APIs with too many parameters, and unhelpful type systems. Often the clarity comes in the wrong layer or at the wrong level: this argument is, again, relevant.
3. Suppose it's true that "it is rarely possible for a programmer to take an arbitrary class and derive a new, useful, and correct subtype from it, unless that subtype is of a very specific [intended] kind." What would follow from that? Compare Item 18 of Effective Java, where Bloch claims that "inheritance violates encapsulation" and famously advocates for composition over inheritance.
4. Alexander and his group once gathered 390 requirements for "what ought to be happening near" a ticket booth. I have never worked on a project where the requirements were not much more extensive than my intuition initially suggested. It's safe to assume there are more requirements than you think there are. (Relevant: this case study that recently made the rounds.)