Patterns Enhance Craft Step 1: Programs is Programs
Until this post I had no idea of the depth of feeling behind the contemporary pattern backlash. One phrase in particular struck me.
Patterns is one of the most powerful ideas we have. Critics may be right that it devalues the craft, but we would all do well to remember that the craft of software in a means to an end, not an end.
This quote took me back to my early days with patterns, when I too struggled with the impact of patterns on craft. This series of notes describes my struggle with the apparent contradiction between patterns and craft and how I resolved it to my satisfaction.

Internal Forces

One of the insights I learned from Notes on the Synthesis of Form is that the forces shaping most design decisions are generated internal to the process of design, not by external constraints. I hadn't really thought about it before, but I would have guessed that most decisions were shaped by what an artifact needed to do, not what it was. An example.
Say we are building an airport terminal. The forces shaping our first decisions are external: so many people and planes per year, budget of thus and so, so many airlines, a contracting process like this. After those first decisions have been made, though, the decisions are quickly influenced mostly by the fact that we are building something--a roof has to support a snow load and a wind load and transfers forces to the walls in certain ways. These forces are internally generated. They have nothing to do with whether the building is financed privately or with a municipal bond.
Now we are designing a barn. This seems like a completely different problem--different budget, different size, different setting, different financing. At first, it is a different problem. We figure out how many of which kinds of animals to shelter, where to put milk storage, and how to provide a separate entrance to the cheese gallery. As the scale of decisions decreases, though, we have to figure out the roof. The list of forces influencing the roofing decision is the same list of forces we encountered in the airport terminal--snow, wind, and so on--although their relative strengths may be different. Again, though, the forces are internally generated.
Turning to programming, I work on software that runs in a carefully-controlled data center, where CAPEX and OPEX are primary concerns and other programs are the consumers of results. I also work on software that runs on hundreds of millions of handsets and browsers, where a person consumes the results and cares about latency and battery life. Different external forces, but most programming decisions are made in response to internally generated forces:
  • Programs use the same bits of logic repeatedly
  • Programs are modified many times
  • Programs consume most of their resources in small percentage of the code
  • People work with programs
These are the forces that programmers resolve many times a day, forces that arise simply because we reason about an uncertain future with a fallible brain.
The next note takes this argument a step further, to notice that programming problems recur.