Maintain Stability using XP

A dominant part of software development and maintenance is adding new or changed features to existing code. This means that the cost of software development and maintenance is in part determined by the maintainability and stability of the code. This is one of the messages the Manifesto for Software Craftsmanship, as shown in Figure 15, is trying to bring across. Delivering well-crafted software is the only way to ensure that business value can be added at a steady, predictable, cost-efficient pace throughout the solution's lifecycle.

Figure 15: Manifesto for Software Craftsmanship

XP is a popular Agile method containing specialist practices for maintaining stability and working on quality. It's practices are inspired by widely used and proven ways of working, taking them to their extremes and leaving out all others that don't directly add value for the customer. In this section we will look at some of the XP practices that are directly concerned with delivering and maintaining quality and aren't addressed in Scrum, RUP or the Agile mindset in general.

Figure 16: Positioning XP Practices

As shown in Figure 16, XP practices can be positioned as part of the daily cycle of Scrum. The practices we treat here can be divided into three groups: the ones concerned with fine scale, early feedback, the ones concerned with continuity in the development process and the ones concerned with shared understanding of the code.

Figure 17: XP Practices for Fine Scale, Early Feedback

The groundwork for fine scale, early feedback, as shown in Figure 17, is laid by Test-Driven Development. It makes sure that we build what the customer wants, forces thinking about design (interfaces, distribution of responsibilities over classes and methods), provides a safety net, preventing mistakes and in that way improves the maintainability of the code. Pair Programming is perhaps the most rigorous form of peer review there is. It makes sure that all production code is viewed by at least two developers, enables knowledge transfer, prevents lonely digging for solutions and stimulates discussion on design issues.

Figure 18: XP Practices for Continuity in the Development Process

Continuity in the development process is provides by Continuous Integration and Design Improvement, as explained in Figure 18. Continuous Integration stimulates developers to check in code changes as soon as possible (as soon as they passed the programmer tests), making them easier to integrate. This way the current status of the solution, passing all tests, can always be demoed to the customer. Design Improvement through refactoring is something that is done very consciously. A developer is either building functionality or refactoring to keep the code clean and maintainable, never both at the same time.

Figure 19: XP Practices for Shared Understanding of the Code

To ensure a shared understanding of the code XP deploys Simple Design, Collective Code Ownership and Coding Standards, as explained in Figure 19. For Simple design the ground rules are that the system runs all the customer and programmer tests, it contains no duplicate code that could increase the maintenance effort, the code is self explanatory and contains the fewest possible number of classes and methods. A nice saying illustrating this practice is ”Always assume the next one to maintain your code to be a homicidal maniac who knows where you live”. Collective Code Ownership enables quicker simplification of complex code and reduces waiting time since anyone feels free to contribute. Shared Coding Standards provides consistently shaped code, making it easier to read and maintain each other’s code.

The key to the success of XP is that it ensures that changing the code is easy and risk free. To realize this, all the XP practices are needed as they enforce each other. They are like a house of cards where all cards support each other to keep the house of cards standing. When all used together the XP practices and values support the creation of high quality software, optimally fulfilling customer needs with a minimum of ceremony and overhead. As such they work great within the Scrum framework and they work equally fine in a somewhat higher level of ceremony environment, say in an organization where RUP is used.

More information on XP practices and values can be found at epf.eclipse.org/wikis/xp.
A nice guided tour of XP can be found at http://www.extremeprogramming.org/.