the death of the architect

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

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