1 Pattern First Thinking

In the beginning, when writing your first line of test code, keep in mind a simple (single) class pattern.  Attentive pattern selection can expedite the journey to loosely-coupled high-cohesion applications.


This figure includes the preliminary PATTERN step that supplements  traditional Test Driven Development (TDD).

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

PED presumes “software flexibility” is an attribute of computer applications valued by stakeholders when 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; including loose-coupling and high-cohesion. Flexibility is prized when it is critical that software be quickly restored to a fully functional condition despite frequent iterations throughout its maturation.

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. Rather, it extends or builds upon this core mantra with a preliminary pattern focus.

Pattern First Thinking makes explicit what many seasoned software engineers periodically practice; an ability to conceptualize target patterns concurrently with constructing test code. Conversely, we have observed that unseasoned TDD developers do not always engage in pattern reflection synchronously with JUnit test implementation. We submit that a defined protocol for prompting pattern consideration encourages globally sustainable code.

It is not the intent for “pattern first” thinking to block traditional Red-Green-Refactor elaboration. Specifically, the Refactor step should continue to enable pattern emergence. Emergence can take the form of moving from an initial simple to more complex pattern if required, or moving from an anticipated pattern to an alternative.

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.

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, an engineer 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 an engineer 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 appreciate that a structurally simple foundation helps sustain maintenance and enhancement of an application. In 2016 we reduced the number of core patterns by almost 50%. Our conclusion: to achieve genuine software flexibility begin with the simplest viable pattern for a given purpose.

Kent Beck, writing in 2007, affirmed an additional benefit of Pattern First Thinking:

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