Why XP?
Robert C. Martin
President, Object Mentor, Inc.

Why is Object Mentor interested in XP (Extreme Programming)? Because we are dedicated to two fundamental principles:

1. Getting the software done quickly.
2. Getting the software done right.

In our experience, one of the key ingredients in the formula for meeting those two conflicting goals is to employ a small, architecture driven, process -- like XP.

We, at Object Mentor, have watched with growing concern as the industry has turned further and further towards heavyweight processes. Apparently those companies and project teams that are deploying these heavyweight processes are under the opinion that their previous software problems have to do with insufficient process. This may be so. However, insufficient is not a synonym for "too small".

In our opinion, the element that is lacking from most processes, heavyweight or otherwise, is a strong emphasis on software architecture. We believe that those companies who are currently deploying heavyweight processes would do better to employ lightweight processes that are focused on producing software with a strong architecture. We believe that such processes result in faster time to market, higher quality software, and highly motivated engineering teams.

XP is a lightweight process that has a very strong architecture focus. It is not divorced from schedule; indeed, it places a lot of emphasis on project management techniques for estimation and schedule management. But its primary concern is to produce software that has strong internal structure. As a result, the software remains easy to modify, easy to extend, and easy to develop. Even for relatively short projects, this leads to significant savings in the cost and time of development.

The most important resource that any engineering manager has is the time of his engineers. Heavyweight processes consume that time with work that is tangential to the project. XP directs and focuses that time onto the software, where it belongs. XP does this by eliminating unnecessary meetings, documents, reviews, etc.

Rather than having engineers produce and review a nearly endless stream of documents that specify the project to be built in gradual increments of ever increasing detail, XP has the engineers work together to produce software in a steady stream of demonstrable increments. Stakeholders see the software come to life before their eyes. Every week or so a new release with more features is available for them to use and comment upon.

But XP does not abandon analysis and design while producing these increments. Indeed, XP puts a premium on both analysis and design. However, it does this without producing lots of *external* analysis and design documentation. The analysis documentation is kept as simple as possible, in the form of user stories written in plain language and continuously reviewed by the stakeholders. The design documentation is maintained by the engineers within the code. Indeed, the code itself *is* the design documentation.

This may seem heretical, however in XP the structure of the code is considered to be of extreme importance. Code that does not qualify as its own design documentation is refactored until it does qualify. Obscure code is not tolerated. Duplicate code is not tolerated. Code that requires massive comments to understand is not tolerated.

Does this mean that XP abandons the use of notations like UML? Not exactly. XP does not incorporate notations into itself. However, it allows such notations to be used by the engineers as a means to communicate to one another about the design; and to make plans for coordinating the development. Just what UML is best at.

In short, Object Mentor is committed to the use of XP because we feel it puts the right emphasis on the activities and artifacts of software development in order to get software done quickly, and done right.

For more on XP, click here...