Continuous Integration
Consider the normal pattern with development: Developers work on their part of the system, and then when completed, integrate with the whole system. The longer the time period between integrations, the more conflicts you'll see, and the effort to integrate will increase. In less rigorous engineering environments, developers work for weeks or months and only integrate at delivery time. As you can imagine, results are disastrous with developers scrambling to build the system for the first time! Nightmare stories of all-night build sessions are all too common.
The extreme of delayed integration is continuous integration. Calling integration continuous is perhaps a little misleading, more of an over statement to say that we should integrate as much as possible. The practice of daily builds is simply not good enough to withstand the speed of XP development.
How continuous integration works in practice is that developers work on a module, class, or component until complete. Then they integrate (add to the integration machine), run tests, fix problems, and move onto the next task. Development tasks are small, and the smaller the better. This bite-sized development fits our object-oriented environment where developers are working on objects, not complete applications. XP tools such as Ant and Nant enable integration at this speed. We'll cover these in more depth in Hour 16, "Automating Your Software Development."