1 Pattern First Thinking

The first principle seeks to inspire software engineers:
In the beginning, when writing your first line of test code, keep in mind a simple class pattern.  In the end, your software will be more flexible.


This figure represents where Pattern First Thinking extends traditional TDD.

Based on experience with “the Company,”[1] we submit that a “pattern first” mindset: is compatible with Test Driven Development (TDD), delivers flexible software to stakeholders, prefers simple class patterns, and provides additional benefits.

In 2003 Kent Beck taught “Test-Driven Development: By Example” including a focus on the “TDD mantra”… Red/Green/Refactor:

1. Red - Write a little test that doesn't work, and perhaps doesn't even compile at first.

2. Green - Make the test work quickly, committing whatever sins necessary in the process.

3. Refactor - Eliminate all of the duplication created in merely getting the test to work.

Pattern First Thinking does not redefine Kent’s “refactor” step like so many others have promoted. Rather, it extends or builds upon this core mantra with an additional step.

Pattern First Thinking makes explicit what many seasoned developers periodically practice; that is, an ability to mentally conceptualize target patterns concurrently with constructing test code. However, we have observed that unseasoned TDD developers do not always engage in pattern reflection synchronously with JUnit test implementation. Said another way, a defined protocol for prompting pattern consideration encourages globally readable code.

It is not the intent for an emphasis on “pattern first” thought to supplant the traditional Red-Green-Refactor sequence. Specifically, the Refactor step should continue to enable pattern emergence. Emergence can take the form of moving from a simple to more complex pattern, moving from an undetermined pattern to an emerged pattern, or moving from an initial anticipated pattern to an alternative. PED presumes “software flexibility” is an attribute of computer applications valued by stakeholders and defined as follows:

Software flexibility is the quality attribute of working software whereby changes to its code base are introduced rapidly while preserving the overall functional integrity of the application. Software flexibility is dependent upon a number of other application attributes that ensures its resiliency. These include the ease with which changes are understood, tested and debugged by the development team. Software flexibility is prized where it is critical that the software be quickly restored to a fully functional condition despite frequent iterations throughout its maturation.

We wish to promote simplicity of structure. We regard patterns as structurally complex if they require multiple Java classes for their implementation, e.g., Model-View-Controller or the Strategy and Adapter patterns.  Simple patterns are generally implementable as a single class.

The common historical division of patterns into structural, behavioral, etc., categories is not our concern.  Rather, our pragmatic indifference is rooted in the notion that patterns may manifest both structural elements and behavioral responsibilities.  It is this sense of simplicity that we read into Kent Beck’s contentions that “simplicity can encourage flexibility” (Beck 2007, 12) and “… the flexibility of simplicity and extensive tests is more effective than the flexibility offered by speculative design.” (Beck 2007, 12)

To achieve software flexibility, a developer might have in mind a pattern that is overly complex for its immediate purpose. Complexity can convey an illusory sense of flexible software, i.e., faux flexibility, where a developer spends additional time on testing and implementation (tantamount to over-engineering), with the imagined benefits never coming to fruition.

We adopted structurally simple patterns in 2004 due to the technical limitations of a specific project team. Only over the next decade did we discover that a structurally simple foundation helps sustain maintenance and enhancement of an application. Our conclusion: to achieve genuine software flexibility begin with the simplest viable pattern for a given purpose. Although our focus is how Pattern First Thinking contributes to software flexibility, Kent Beck, writing in 2007, affirmed an additional benefit (i.e., speed):

Once a set of implementation patterns has become habitual, I program faster and with fewer distracting thoughts.  When I began writing my first set of implementation patterns (1996) I thought I was a proficient programmer. To encourage myself to focus on patterns, I refused to type a character of code unless I had first written down the pattern I was following. It was frustrating, like I was coding with my fingers  glued together. For the first week every minute of coding was preceded by an hour of writing. The second week I found I had most of the basic patterns in place and most of the time I was following existing patterns. By the third week I was coding much faster than I had before, because I had carefully looked at my own style and I wasn’t nagged by doubts.


[1] In 2002, Java was adopted as the standard platform for in-house development at a successful large automotive manufacturing enterprise (“the Company”).

Beck K. 2007. Implementation Patterns. Addison-Wesley