Jeremy Hylton : weblog : 2003-06-05

XP and Design

Thursday, June 05, 2003

Are "bad smells" in extreme programming projects caused by a lack of up-front design? Elssamadisy and Schalliol from ThoughtWorks wrote a paper describing problems they had in a large (50-person) project that used XP.

One example from the paper is a project where a large refactoring project was delayed on grounds of doing the simplest thing. They believed that they would eventually need general framework, but at each iteration they made only minimal steps towards it.

Recognizing Bad Smells in XP:

What we SHOULD have done is realize that it is OK to look ahead and trust our inner-instinct that we are going down the wrong path. We should have continued to do thing incrementally, but after the first instance we should have pulled the work and made it into a factory instead.

The authors later argue that

if you find yourself having to do a large refactoring then you should have done many smaller refactorings earlier and you got lazy.

It seems just as likely that you should have spent more time designing the framework upfront. I think you ain't gonna need it (YAGNI) is a fine principle, but I believe there are also cases where you know you will need it. If you know you will need it, then taking many small incremental steps is probably more expensive that spending a little more time upfront to get the design right.

I saw a reference to the paper in the June issue of IEEE Computer has a collection of articles on "agile software development." There's a bizarre debate between Kent Beck and Barry Boehm. There is also an interesting history of iterative and incremental development. It sounds like the less extreme parts of XP have been around for a long time. When I first heard about XP, it reminded me of Brooks's advice:

Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.