This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Reference
A similar list of problems is also given in Chapter 1 of Extreme Programming Explained.
There’s a good discussion of risk management in Chapter 5 of Steve McConnell’s Rapid Development (Microsoft Press, 1996).
Alistair Cockburn, Agile Software Development ( NewYork, NY: Addison-Wesley, 2001 ), p. 142.
This is referring to a quote from Kent Beck in Extreme Programming Explained,in which he states that we should “take all these good things and turn the knobs up to 10”—in other words, do all of them all the time.
See http://c2.com/wiki?XpXtude.
Chet Hendrickson, “When is it not XP?” http://www.xprogramming.com/xpmag/NotXP.htm December 5, 2000.
For an interesting discussion, see http://c2.com/wiki?xpCourageValue. We can see from this page that the Extremos were originally debating between courage and aggressiveness (not to mention confidence, fearlessness, boldness, and ruthlessness) as a possible name for the value. “Our chief weapons are.”
XP takes the approach that the software should be ready to release at any time, just in case the project is suddenly cancelled. We prefer to take a more realistic approach and plan ahead to specific release milestones.
XP recommends tailoring its practices to local conditions, although (as we describe in Chapter 3) it contains little guidance for doing so, and in many ways tailoring XP can be a risky business.
In XP, collective ownership also helps, in that sooner or later someone else on the team will notice some bad code and refactor it. This is a little too ad hoc, though—it leaves a lot to chance. A more rigorous approach is to schedule regular reviews (not necessarily with a big group of people, because this can be demoralizing for the person whose code is being analyzed). This coupled with up-front design reviews helps keep your code in shape.
Scott W. Ambler, Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process ( New York, NY: John Wiley & Sons, 2002 ), p. 188.
For an example of test-first design in practice, see http://www.objectmentor.com/resources/ articles/tfd.pdf.
Although we part ways again when XP goes really abstract and ascends into Zen-esque philosophy to justify its practices, as we discuss in the final chapter.
Luckily the Extremos have also seen the light and refactored the XP customer role to mean a team of analysts (as we discuss in Chapter 5).
This may sound blatantly obvious, but that’s possibly because it is such basic, profound advice. We’re still amazed at the number of projects we see or hear about that contain one or more bad programmers.
QA also has its own separate test environment, but running the tests regularly in Engineering means that not only are the functional tests testing our software early, but also the software is testing the functional tests early as well. This virtually eliminates the “big bang” delivery problem, which affects test scripts equally as much as it affects production software.
Matt Stephens, “Automated Code Generation,” http://www.softwarereality.com/programming/ code_generation.jsp, May 6, 2002.
We’re using Java properties files for this purpose because they’re much simpler to work with than XML (not to mention easier to read and edit). If the project increases in complexity and demands more flexibility, we will change as needed.
XPers tend to view this practice with quaint amusement, and yet this was a primary factor in the early termination of the C3 project (as we discuss in the sidebar “Did Oral Documentation Kill C3?” in Chapter 7).
See http://www.dsdm.org.
See http://www.togethersoft.com/services/tutorials/jmcu/chapter6.pdf.
See http://www.rational.com/products/process.jsp.
See http://www.iconixsw.com/ICONIXProcess.html.
Rights and permissions
Copyright information
© 2003 Matt Stephens and Doug Rosenberg
About this chapter
Cite this chapter
Stephens, M., Rosenberg, D. (2003). Refactoring XP. In: Extreme Programming Refactored: The Case Against XP. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4302-0810-5_15
Download citation
DOI: https://doi.org/10.1007/978-1-4302-0810-5_15
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-59059-096-6
Online ISBN: 978-1-4302-0810-5
eBook Packages: Springer Book Archive