What Is This Change of Which You Speak?

Change in XP (and, in fact, in every other software process ever) operates at two levels:

• Changes to requirements

• Changes to architecture/design

Changes to requirements usually involve some form of impact analysis, where the customer is given enough information to decide whether the change is worth pursuing. For example, adding this module will take an extra 2 weeks; or deciding that the system must cope with up to 10,000 transactions per hour , not 100 as originally decided, will involve a significant architectural change that could add an extra 6 months to the project. Given such information, the customer may decide to go ahead, or to postpone the change until a later release, or not to make the change at all.

Changes to architecture/design are often a direct result of a change in requirements. Also, a design change can be a result of increased understanding of the solution (whereas a requirements change is a result of increased understanding of the problem).

In XP, changes are handled by dividing the project into short iterations of 1 to 3 weeks. A shift to a completely new architecture would involve many, many short baby steps, gradually changing the design until the new architecture is reached. Of course, baby steps may not always be possible. At some stage (for example) a giant leap might need to be made if the change is as fundamental as a migration from .NET to a J2EE architecture.

See Chapters 9 and 12 for more about refactoring and emergent design.