Extreme Programming

Extreme programming (XP), created by Jeff Beck, contains a lot of good assumptions and practices to lay the ground for a working development method. It focus on producing working code, it is iterative and it is incremental. Its weak areas are architecture and design, where it simply is too extreme.

Extreme projects constantly change focus, requirements are dropped an added from day to day. But projects are almost never this extreme. Most projects benefit from a certain degree of architectural planning. The amount of planning suitable for the project will be a value judgement that is continuously evaluated. The things that can not be handled with planning must be handled with refactoring. Just don't do everything through refactoring. There are no silver bullets, but this is the only option XP gives you. XP offer no solutions on how to plan the architecture and design ahead of time.

XP stipulates that with a single system metaphor as a guide, the architecture and the design will grow out of the code with continuous refactorings when new functionality is added. Within XP, it is known that this sometimes leads to deadlocks, where you can not add new functionality without breaking old. Then, a time-out is supposed to be taken, and the broken system is redesigned. If the deadlock could have been anticipated due to the character of the project, it would be irresponsible to drive it into this dead end without a second thought. Don't expect one single practice to be the solutions to all your problems. Make an informed judgement.

Proper planning is important if you want to succeed with large projects. Otherwise, everyone will be stepping on eachothers toes all the time. Describing the envisioned architecture is an important part of the planning. Through the architecture, one metaphor per component and language can be created, and the work can be divided between the team members.

XP does not encourage custom languages, code generators and configurable components, because these things can not be created through refactoring. Refactoring only deals with structural changes within the implementation of one language, and have no means to create new languages.

There is one area where XP has the potential to be very successful, and that is in the design and implementation of components. The code is small enough to make refactorings practical. The on site customer are other component developers, which makes the requirements planning feasible. Automatic testing of components are desirable and practical, and this integrates well with test driven design as used in XP. One metaphor per component is more realistic than one metaphor for the entire system.