decoupling in depth

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