a brief introduction

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 the fractal-metaphor, our software is an open space. Each reader traverses that space, noting new details as they come into view. When our software is well-designed, these details are small and incremental. But this isn't quite right. If it were, movement through our software would satisfy the triangle inequality: In Euclidean geometry, if AB...

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...