XP Design Mantra: No BDUF

GROUCHO  

What could be more courageous than stopping after a little bit of design, confident that when the time comes, you can add more, when and as needed? ^[6]

The XP design mantra of no BDUF is perhaps the most important, because it is central to the way in which XP impacts the project life cycle. It removes the waterfall element, and it is what makes XP an incremental process.

The theory is that a small amount of design is produced up front solely for the user story that you re about to implement. Any design documentation produced is purely transient, however (similarly, the design is transient because it may get refactored). If the design is written down at all, it doesn t matter if it gets lost or thrown away because it s stored in the collective consciousness of the team (at least, that s what the XP authors teach us).

One important aspect is that the programmers are going straight from user story to testing/programming/design, which are all done concurrently. Even upfront design is optional ”it s best to do some, but if you don t it doesn t really matter.

This effectively eliminates architectural documents and de-emphasizes the up-front design process to the point where it s almost nonexistent.

The replacement is a technique known as test-first design (as described at the beginning of this chapter). In fact, this technique, essentially a subset of XP, has been wrapped up in a process called test-driven development (TDD). TDD is described in Kent Beck s book Test-Driven Development: By Example . Given the somewhat controversial nature of XP, separating the test-driven aspects of XP into a stand-alone process with a sensible name was a wise move.

Unit tests aren t specifically an XP thing. You can make extensive use of unit tests without labeling yourself an XPer. In fact, if you retain just one thing from XP, be sure to make it unit tests.

Being able to run your tests and see a green light at the end gives a boost of confidence. You can run your tests before making the change and afterward, to make sure the green light still lights up. Some people claim that this makes programming somehow more satisfying than it already is (as if that were possible).

As ever, there is a note of caution (an entire octave, in fact).

^[6] Kent Beck, Extreme Programming Explained: Embrace Change (New York, NY: Addison-Wesley, 2000), p.104.