- Uncovering Software Development Problems
- Controlling Risk with XP
- Improving Quality with XP
- Managing Change with XP
- Summary
- Q&A
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
Managing Change with XP
We've seen how projects spiral out of control. Huge budget blowouts such as the DIA baggage system are all too common. Studies by software measurement experts such as Quantitative Software Management (QSM) show that costs associated with development grow over the life of the project. Figure 3.2 illustrates the costs of development.
){kind=link}
Figure 3.2 The rising cost of development.
NOTE
See Q&A section at the end of this chapter for more resources on software quality.
The simple correlation between time and cost explains why software projects spend so much time in up-front planning. Measurements taken by QSM prove a definite link between time spent in careful planning and requirements gathering up-front and lower costs. When development starts the burn-rate of the project accelerates and costs can sky rocket. This explains why Waterfall approaches effectively tie the hands of the customer before work begins. Without sign off and fixed scope, the customer could request changes during development, and change at this stage is costly and difficult. This makes perfect sense as changing requirements before construction involves changing documents; no real work has been done yet!
NOTE
Contrary to what you might expect, spending more time in development does not always lower the defect rate. In fact, there is an optimal time to spend; you need a fine balance between time and quality. See Applied Software Measurement by Capers Jones (1991) for more on this.
XP offers a completely different paradigm: What if the cost of change could be flattened? What if the cost to change your software project was the same during construction as that during requirements gathering? This is exactly what XP does! Before explaining how this happens let's consider what the implications of leveling out the cost of change. Figure 3.3 shows how XP equalizes the cost of change.
){kind=link}
Figure 3.3 Flattening the cost of development.
If the cost of change could be leveled, the need to specify exact requirements would be removed. The development team could leave some questions unanswered and begin construction based on what is known now. Also, we'd no longer feel obliged to demand that the customer "crystal ball gaze" about their possible future requirements. The project would be more like a journey whose final destination is not known. If the customer is directing with the team quickly delivering business value for feedback, it can work.
To summarize, XP accepts change and seeks to flatten the cost of change over the life of the project. This way you can postpone decisions until later, when they may or may not be required. Table 3.5 lists some key ways XP levels your cost of change.
Table 3.5 XP Cost Flattening Practices
|
Practices |
Approach |
|
Objects |
Using object-oriented programming techniques means developers are able to simplify code with data hiding, abstraction, and other features. |
|
Message-based protocols |
Message-based protocols enable the development of systems that decouple your systems from those you interface with. You can effectively draw a line in the sand separating your development from the outside. Emerging standards, such as XML, are frequently used as a soft, yet robust, interface. |
|
Simple design |
Building and developing only those features required by the customer is rooted in the idea that simplicity is best. Automated testing and object-based tools enable simple design. |
|
Automated testing |
The automated test harness is a constantly growing framework of tests that run against the system. The tests were written before the code and are executed returning hard defect metrics. Developers can change code with courage, as their test suite will quickly report on code quality. |
|
Refactoring |
Simplifying code is second nature to XP developers as they refactor existing code and have consistent practice with redevelopment. Rather than be tentative about replacing a poor performing module or class, they have an attitude that expects change. |
These practices will not on their own be a guarantee that development costs can be flattened, but they do allow a new style of high-speed, confident development to occur. In reality, XP practices and standard software development best practices work together to maintain a level development cost throughout the life of your software product.