2 0
IEEE SOFTW ARE
Published by the IEEE Computer Society
0740-7459/04/$20.00 © 2004 IEEE
design
E d i t o r : M a r t i n F o w l e r ■ T h o u g h t Wo r k s ■ f o w l e r @ a c m . o r g
T
he rising popularity of refactoring, tools
such as JUnit, and agile methodologies
such as Extreme Programming (XP) has
brought a new style of design into view.
Continuous design is the process of us-
ing refactoring to continuously improve
a program’s design. Initially a skeptic, I’ve been
experimenting with continuous design for four
years, and it’s changed the way I program.
The role of continuous design
Continuous design is also known as evolu-
tionary or emergent design. I prefer the term
continuous design because it emphasizes the
core of the process: continuously taking advan-
tage of opportunities to improve
your design. When you discover a
design flaw, you fix it. When a new
feature doesn’t fit, you update the
design. (For an introduction, see
Martin Fowler’s “Is Design Dead?”
at www.martinfowler.com.)
Continuous design can coexist
with up-front design, but the XP
approach advocates the former in-
stead of the latter. When I started
experimenting with XP in 2000, I
was very skeptical of the idea. I’d been in-
volved in projects that had painted themselves
into a corner with bad design, and I was con-
vinced that up-front design was necessary to
avoid that problem. When I tried XP, I hedged
my bets: I designed a layered architecture and
persistence model up-front.
The persistence model was a disaster: it re-
quired a huge amount of code to do simple
things. Continuous design, however, was a roar-
ing success. The application, developed over 16
months by six people, had the best design I’d
seen. Bit by bit, continuous design fixed the per-
sistence model too, eventually giving us an ele-
gant solution that was simple and flexible.
My initial success with continuous design
inspired me to continue experimenting. My
up-front designs became simpler and simpler ...
then disappeared entirely. Today, when I start
a projec