TITLE: Design in Agile Methods
AUTHOR: Eugene Wallingford
DATE: January 23, 2009 1:02 PM
DESC:
-----
BODY:
I recently read an early version of a paper by a
colleague in the agile world that talks about several
different ways he approaches design problems. I
like that he is writing about design. After all
these years, I still encounter many people who think
this statement is an axiom:
agile development → no design
In those situations, I try to share (gently) my
experience as developer and occasional consultant,
but the notion is pretty well ingrained. As I
wrote last month,
it's hard a slog.
As I read the preprint, I thought more about doing
design in a reactive way, responding to new features
as we add them to our code. My skeptical colleagues
think that the sort of design so many of us do in
agile settings is not design at all. But I think
they are wrong, and the word "reactive" brought to
mind a similar notion from my days in AI:
reactive planning.
When I first heard that term in a graduate readings
course, it sounded like an oxymoron to me. Planning
is the opposite of reaction, right? If an agent
does not construct a plan, then how is it planning?
Reactive planning contrasts with what then came to
be known as
classical planning.
An agile wag wag might coin the term "BPUF" -- big
planning up-front.
But I learned about the idea and found it wasn't an
oxymoron at all, that reactive planning was a real
and valuable way for an agent to prepare its actions.
I have learned the same is true of "reactive" design.
We folks in the agile world probably haven't done
enough to teach agile novices to design in this way,
which is one reason I'm hoping to see more papers like
the draft I just read.
-----