A Philosophy of Software Design — Episode 4

Alexey introduces himself: he builds architecture processes across the investment business and keeps teams involved in shared decisions. His verdict on the book: it describes typical problems well and offers quick, applicable fixes; the advice inside a section sits at different levels but all of it is relevant, and the section on agile and code quality is clearly written from lived pain, so he would recommend the book to all of his developers. The participants regret again that they did not read it fifteen years ago. By their account the author first turned the material into a student course and only then a book; he is one of the developers of the Tcl language and cites the refactoring of the Tcl compiler to bytecode, along with RAMCloud, apparently a distributed in-memory store. Chapter twenty-one is absent from the first edition, and the club sorted the twenty-one continuous chapters into blocks of its own — an intro on complexity, fighting it, documentation, now the generalisations — since the author never split the book into parts.

The consistency chapter opens with a simple definition: the same tasks should be solved the same way, different ones differently. The examples are familiar: naming without synonyms and a code style that has to be agreed and written down, helped by IDE configs and languages that ship a formatter out of the box. Then interfaces: a deep module hides behind one simple interface, and the author points to file and network I/O, where the complexity moves inside the implementation. The participants recall the Liskov substitution principle: a mental model carries over from one implementation to the next. A caveat for distributed systems: the contract is there, but behaviour can be very surprising, so an interface also wants its behaviour described for various situations, and the author splits an interface into a formal and an informal part where signatures alone are not enough. The word invariants brings back a 1200-page brick on object-oriented design that one participant abandoned around page two hundred three or four times; its author invented contract programming.

The author offers three ways to hold consistency. First, documentation: conventions and invariants must be written down so a newcomer does not get them by word of mouth. Second, enforcement through tooling: linters, checkers and fitness functions that verify even a custom agreement at build time, as long as it stops short of linter hell. Third, do as the Romans do: never bring your own code style into someone else's project, or ten standards become eleven. One more tool is code review, where a newcomer's first review should be as detailed as possible. Alexey splits this in two: study how decisions are made on the project even when nothing is written down; and if you do change a convention, weigh the risks and the cost and work out why it was made that way. The author adds a retirement plan for the old convention so no tails are left, and a host notes that selling changes to people is closer to a managerial-track skill.

The chapter on obviousness rests on the idea that obviousness belongs to the reader, not the writer. The working method: if you are asked at review what a piece of code says, answering that it is all clear is only your point of view, and the question alone is reason to comment or rewrite. One participant feels the author dumped thoughts of very different levels into the chapter, from comments to event-driven style, which is already architecture. To the earlier recipes of naming and consistency the author adds comments and whitespace alignment; a host recalls markdown files next to code with not a single blank line between headings and text. Alexander links obviousness to high- and low-context cultures: when both know the patterns, naming one carries the whole idea, and without shared context comments, code structure and documentation need far more words. Hence an onboarding page: read these books and patterns first, which is normal and saves time.

The trends chapter is walked through on a large diagram a participant drew himself. Object-oriented programming is thirty or forty years old: interface inheritance reduces the complexity of knowing contracts, while implementation inheritance is openly criticised, since it repeats logic across implementations and leaks information, for instance handling of a file format; composition and helper classes are recommended instead. Functional programming is absent from the trends although the participants call it a major one: asynchronous chains of events come out simpler in it, yet candidate cards show how five or six chained calls with deep nesting take long to unfold in a reader's head. Agile grew out of dragged-out early-nineties projects where the product was no longer needed by launch; the author demands that increments be increments of abstractions and blames agile for tactical programming, and a host compares that to gradient descent: without a big picture you find a local extremum and end up needing version 2.0 rather than a refactor. A viewer, Dmitry Ulyanov, asks for examples of increments in abstractions; nobody recalls the author's own, so they offer a contract that stays unchanged while the implementation grows.

Patterns make design and reading easier but tempt people to force everything into a ready-made one — a hammer that sees only nails. Unit tests get praise: after the Tcl compiler refactoring the alpha release had a single bug. TDD is criticised for fitting the solution to test cases, yet even there the author finds an upside: write the test first when fixing a bug. On performance: measure rather than optimise everything, design around the critical path, and rewrite a path overgrown with checks as the simplest function without corner cases. The final chapter comes down to the point that not everything can be important: the rest hides behind deep modules and default parameter values, and the participants mention Kotlin defaults and partially applied functions in Scala. One host admits the chapter left a feeling of common sense, though such a mental model fifteen years earlier would have sped him up; alongside it comes a story of a system built over four years for a promised million concurrent users that never came at launch. The wrap-up: a small essayistic book they wish they had read earlier, its red-flag list hidden behind the index, then a two-week break and a vote for the next book.