One of the most widely discussed problems in our business is the number of application development projects that get bogged down and are either never delivered, are very late, or never work right. Close behind it is the problem of projects that are delivered to spec, but turn out not to solve the problem at hand.

There's a new programming methodology that aims headfirst at these problems. The technique is called "Extreme Programming," or XP for short. Its fundamental idea is to break a project into small, achievable steps with frequent releases and extremely rigorous testing. It's geared primarily at high-risk projects or those where the requirements are either not yet well-defined or are likely to change frequently. XP is designed for small development teams.

How it works

The project is divided into a series of iterations (generally three weeks) and each iteration ends with a release. To determine what goes into each iteration, the first step is to collect the "user stories" for the project. The development team estimates the time to implement each user story, measured in "ideal development time," that is, if the problem was perfectly defined and there were no interruptions. User stories (which serve a similar role to use cases) are broken into smaller parts until they reach a size where the team estimates they can be completed in three weeks or less of ideal development time. The customer then indicates which user stories are most important, and those get priority.

One of the key features of XP is that you always do the simplest thing possible. Nothing is ever implemented just because "we'll need it later."

"Refactor mercilessly" is also one of XP's most fundamental rules. Refactoring means revisiting and restructuring code to simplify it. It's important not to get wedded to a piece of code simply because it's working. If you can rewrite it by pulling out redundancy and getting rid of unused functionality, the result will be easier to maintain.

Testing plays an extremely important role in XP. Unit tests (tests for one chunk of code, perhaps a class) are created before or in conjunction with the code. The code can't be released to the project as a whole until it passes all the unit tests. Any time code is modified, it must be unit tested again and can't be released until it passes every test. The customer helps to create acceptance (or functional) tests for each user story. Both kinds of testing are automated, so it's easy to test whether the particular module or the current version of the application passes.

Personnel issues

As with any serious methodology, XP requires the use of coding standards. But with XP, standards are even more important than usual. This is because of what might be the biggest difference between XP and traditional programming approaches -- the way people are managed.

Programmers work in teams of two, called "pair programming." Each pair sits in front of a single computer sharing the keyboard and mouse, as needed. While this technique sounds terribly inefficient at first, it reminds me of some of the best problem-solving sessions. The proponents of XP claim that, in the long run, pairs produce the same amount of code as two people working alone, but the code is better.

Just as code is refactored on a regular basis, with XP, so are the pairs that produce it. XP calls for collective ownership of code, so rather than having one group always assigned to the user interface, while another owns the data, everyone works on everything at one time or another.

Developers are moved from one task to another and pairs are broken up and reformed. In this way, everyone on the team is familiar with the entire project. If one area gets bogged down, others can work on it without the need for extensive training. One of the rules for XP speaks to the part of me that believes in having a life. "No overtime" means what it says. The team works 40-hour weeks. With the opportunity to enjoy life, get enough sleep, and refresh their minds, people are more productive.

XP and VFP

There are other aspects of XP that I haven't mentioned, but this is enough to give you an idea. XP is just beginning to be discussed seriously in the VFP world. Aside from the issue of asking people to change the way they work, there are some apparent difficulties in applying XP to VFP development. The biggest is the automated testing requirement. Test harnesses have been created for a number of programming languages, but to date, there's none for FoxPro. I don't think this is an insurmountable problem, though. Another issue is trying to apply iterative development and refactoring to databases, where small changes can wreak havoc with existing code.

I'm intrigued by Extreme Programming. Over the next few months, I intend to see which of its techniques I can use effectively.