The Art of Agile Development, 2nd Edition

Reflective Design

AUDIENCE

Programmers

Every day, our code is better than it was the day before.

Traditional approaches to design assume code shouldn’t change. Instead, new features and capabilities are supported by adding new code. A traditional design supports this by anticipating what might be needed and building in extensibility “hooks,” in the form of inheritance, dependency injection, and so forth, so code for those features can be added in the future. The Open-Closed Principle, a classic design guideline, illustrates this mindset: “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”

But Agile teams create simple designs that don’t anticipate the future. Their designs don’t have hooks. Instead, Agile teams have the ability to refactor their code and change its design. This creates the opportunity for an entirely different approach to design: one in which entities are not designed to be extended, but are designed to be modified instead.

I call this approach reflective design.

How Reflective Design Works

Reflective design is in contrast to traditional design, which I call predictive design. In predictive design, you predict what your software will need to do, based on your current requirements and best guess about how those requirements might change, then you create a design that cleanly anticipates all those needs.

In contrast, reflective design doesn’t speculate about the future. It only cares about the change ...