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.
References
Alistair Cockburn, Agile Software Development ( New York, NY: Addison-Wesley, 2001 ), p. 169.
Amr Elssamadisy, “XP On A Large Project—A Developer’s View,” http://www.xpuniverse.com/2001/pdfs/EP202.pdf paper presented at the 2001 XP Universe conference.
Ibid. We analyze the paper containing this quote and the last in the “Painting Over the Cracks” section in this chapter.
As we explored in Chapter 5, this has proved to be the case generally in XP
See the section “Extreme Programming in Theory” in Chapter 1 for a brief description of pair rotation. Also see Chapter 6.
Presentations are useful to bring the design to life and communicate it effectively to developers. Writing the design down (and keeping it up-to-date) can also save a lot of wasted work and misunderstanding.
Amr Elssamadisy, op. cit., p. 5.
At least, it’s vital in XP because the practices are taken to extremes.
Amr Elssamadisy, op. cit., p. 4.
The XP mantras “you aren’t gonna need it,” “Do The Simplest Thing That Could Possibly Work,” and “[Don’t do a] Big Design Up Front” are all described variously throughout this book.
The first 90% is always easy. Fear might be the mind-killer, but it’s that second 90% that is always the killer on software projects. To (mis)quote Marvin the Paranoid Android from Douglas Adams’ The Restaurant at the End of the Universe “The first 90% was the worst. The second 90%, that was the worst too. After that we went into a bit of a decline….”
Kent Beck posting to OTUG (http://www.rational.com), subject: “XP and the real world,” March 1, 1999.
Pete McBreen, Questioning Extreme Programming ( New York, NY: Addison-Wesley, 2002 ), p. 87.
One of Doug’s favorite mental images is to imagine emergent architecture on something like a really big jet-fighter project. Developed over a decade or so by multiple companies, with multiple teams participating within each company, all geographically distributed, building real-time embedded software that has to respond in the millisecond/microsecond time frame or people die—really quickly.
Rights and permissions
Copyright information
© 2003 Matt Stephens and Doug Rosenberg
About this chapter
Cite this chapter
Stephens, M., Rosenberg, D. (2003). Scalability. In: Extreme Programming Refactored: The Case Against XP. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4302-0810-5_14
Download citation
DOI: https://doi.org/10.1007/978-1-4302-0810-5_14
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-59059-096-6
Online ISBN: 978-1-4302-0810-5
eBook Packages: Springer Book Archive