Fitz

Years ago, a friend in the software development industry introduced me to the Extreme Programming software development methodology, or XP. Since then, I’ve noticed many of XP’s principles creeping into my own office. Some of the main points of XP include:

* breaking a project lifespan into iterations
* frequently producing small releases
* programming unit test cases first
* using simple, streamlined design
* only adding functionality that meets a requirement of the current iteration
* frequent code refactoring
* constant customer interaction

Many believe that XP’s principles are not effective unless they are all applied to the development process. Some of these ideas, though, seem to me like general good practices. For instance, heavy customer involvement in the development process could help in many stages — requirements gathering, testing, scoping the level of effort, to name a few — whether or not any of the other practices are used.

I had a discussion with a coworker the other day concerning XP’s usefulness for maintaining existing code. He argued that some of XP’s practices don’t make sense for maintenance tasks, particularly programming unit test cases before making code changes. I can see his point; it seems wasteful to spend time writing unit tests for components that apparently already work properly. But what if we started a unit test for a component that needs a bugfix, adding tests to illustrate the component’s failure. Then we can consider the bug fixed when the component passes its unit test. As additional bugs pop up for the component, we add to the unit test for that component. Not only can we be assured that the bug is resolved, we can also be certain that our fix hasn’t broken previous fixes.

It’s true — XP’s practices are less useful for maintenance compared to new development. But I still believe there’s value to using some of its ideas in software maintenance.