Summary

There s a lot to be said for emergent design when it s used in moderation and under the correct circumstances. We ve noticed a common reaction in people when we describe the concept to them: Woo-hoo, on the face of it this makes so much sense! When you think about it, your understanding of the design really does change once you start programming! The design does evolve ! Then, when they really do think about it, they realize that there s something missing. Even if they use the full XP design arsenal ”emergent design, refactoring, test-first design, YAGNI, and so on ” they miss out on an essential and timesaving aspect of software development.

XP appears to be stuck in the initial on the face of it reaction. Dismissing the benefits of up-front design and early prototyping is just plain unwise, because it is possible to get a design pretty close to correct if you use the right approach. That isn t to say that the design will be perfect, but it will be stable enough, for example, for multiple teams to begin coding to the same design.

It has been argued that emergent design is a good approach for a project where the requirements are not clearly defined (i.e., they keep changing). We examine this aspect of XP in the next chapter.