Category list

References

[Beck1997] K. Beck. Smalltalk Best Practice Patterns . Prentice Hall, 1997.

[Beck2000] K. Beck. Extreme Programming Explained . Addison-Wesley, 2000.

[Beck+2001] K. Beck, M. Fowler. Planning Extreme Programming . Addison-Wesley, 2001.

[Brooks1995] F. Brooks. The Mythical Man-Month, Anniversary Edition . Addison-Wesley, 1995.

[Jeffries+2001] R. Jeffries, A. Anderson. Extreme Programming Installed . Addison-Wesley, 2001.

[Jzquel+1999] J. Jzquel, B. Meyer. "Design by Contract: The Lessons of Ariane." Computer , Volume 30, January 1999.

[Liskov1998] B. Liskov. "Data Abstraction and Hierarchy." SIGPLAN Notices , Volume 23, May 1998.

[Meyer1997] B. Meyer. Object-Oriented Software Construction , Second Edition . Prentice Hall, 1997.

Acknowledgments

We thank Bertrand Meyer for giving interesting and entertaining talks that introduced us to the concept of contracts; our employer, the Daedalos group , for providing the resources and patience while we were researching the topic presented here; and our partners and families for bearing with us while we were immersed in it.

About the Authors

Hasko Heinecke and Christian Noack both work for Daedalos International AG in Switzerland and Germany, respectively. They have a strong background in OO technology and the Smalltalk programming language, complemented by several years of experience in Java. Not being advocates of any one programming language, they are more interested in the inner workings of object-orientation itself and its implications on project management. They can be reached at hasko.heinecke@daedalos.com and christian.noack@daedalos.com.

Chapter 18. Refactoring or Up-Front Design?

—Pascal Van Cauwenberghe

Among supporters and detractors of XP, the debate rages whether up-front design or incremental design combined with refactoring is the optimal method of implementing systems. This chapter argues that neither method is clearly better in every circumstance. Instead, the experienced software engineer uses a combination of both methods . This chapter also argues that the "cost of change" curve presented in Extreme Programming Explained [Beck2000] does not replace the classic "cost of fixing errors" curve presented by Barry Boehm in [Boehm1981]. Instead, XP is a method of attacking the costs described by this curve.

XP, as an incremental method of software engineering, is only applicable in circumstances where the cost of implementing functionalities does not grow rapidly as development progresses. Some heuristics and examples for deciding when to use each technique are presented.

Introduction

In Software Engineering Economics , Boehm presented the classic cost curve shown in Figure 18.1. As we progress from analysis to design, coding, testing, and production, the cost of fixing a problem rises. Note that the sharpest rise occurs when the system is released and distributed to its customers.

Figure 18.1. The "cost of fixing errors" curve

graphics/18fig01.gif

In Extreme Programming Explained , Kent Beck argues that this curve no longer represents the current state of software engineering. Instead, this curve is said to be flat. Two remarks can be made.

Originally, this curve represented the cost of fixing errors introduced in earlier phases of a project. Kent Beck presents the curve as the "cost of change " curve.
In his online article "Reexamining the Cost of Change Curve," Alistair Cockburn demonstrates that the cost of fixing errors still rises rapidly as the project progresses [Cockburn2000].