structures as paths

Once upon a time, every project began with the creation of a canonical design document. This was called the system architecture, because it "rightly implie[d] the notion of the arch, or prime, structure."1 Then, documents would be written for each module. These would provide detailed instructions for how the module should be implemented. ...

Previously, we explored how abstract explanations, paired with intent, become specific. And in our case, the intent is almost always to improve our software. But what does this actually mean? To begin, let's consider this metaphor: Things are looking up This is a statement of optimism: things are improving, and we expect this trend to...

There was, in the mid 2010s, a popular formula for explaining a new startup: "Uber, but for ____." This was a metaphor: the startup, despite targeting a different market, was similar to Uber. It was, however, a fairly ambiguous metaphor; there were many ways that a company could resemble Uber. The most visible facet of Uber was their use of a...

In his influential paper On the Criteria To Be Used in Decomposing Systems into Modules, David L. Parnas offers some simple, timeless advice: if two things change together, they belong together. This is not, in itself, an answer. It simply replaces a nebulous question — do these belong in the same module? — with something more concrete. In...

In the software design literature, cohesion is often referred to by a different name: single responsibility. As Sandi Metz explains it: When everything in a class is related to its central purpose, the class is said to be highly cohesive or to have a single responsibility.1 To determine if a method belongs inside a class, Metz suggests posing it...