Pete McBreen - Questioning Extreme Programming

"I come to bury Caesar, not to praise him."

William Shakespeare, 1599; Julius Caesar, act 3 scene 2

This has been a very interesting book to write. When I first heard about Extreme Programming I was very excited because I actually enjoy programming. Over time, my questioning of Extreme Programming has led me on a journey that is practically the opposite of Anthony's eulogy for Julius Caesar as told by Shakespeare.

At the end of Anthony's eulogy, the mob is on Caesar's side and is lusting for revenge on the conspirators who killed Julius Caesar. In my case, I started off very enthusiastic and, over time, became much less so because of the very narrow applicability of Extreme Programming. Sure, XP teams have managed to do great things, but suitable projects are few and far between. I have yet to work on a project that was really suitable for XP and I suspect that few other developers have.

Yes, if you can meet the preconditions, Extreme Programming can be very successful, but so would practically every other approach to software development as well. True, Extreme Programming is nearly unique in insisting that organizations create the right conditions for the project to be successful, but the reality for most projects is that they must be carried out in suboptimal circumstances. Common problems are things like facilities that make it impossible to colocate the entire team, slow decision making, and users being inaccessible. Any and all of these factors create circumstances under which Extreme Programming as originally defined cannot be used.

One way around this difficulty is obviously to attempt to bend XP to fit the circumstances. "Distributed" XP is one example of how a team can attempt XP without being colocated. Other teams have tried XP without an On-site Customer, without Pair programming, and even without organizational support. In the end, though, I think all of these attempts miss the point of Extreme Programming.

For me, it all comes back to the statement that Ron Jeffries made in Oslo that the "Entire team agrees this is the best project they've ever been on." The whole purpose of using Extreme Programming is playing to win. Rather than accepting suboptimal compromises, find a project that enables you to do Extreme Programming the way that it is meant to be done. After all, Software development is meant to be fun. If it isn't, the process is wrong.

And now for some light reading

[Auer, 2002] Auer, Ken, and Roy Miller. Extreme Programming Applied . Boston: Addison-Wesley, 2002.

[Baetjer, 1998] Baetjer, Howard. Software As Capital . Los Alamitos: IEEE Computer Society, 1998.

[Beck, 2000] Beck, Kent. Extreme Programming Explained . Boston: Addison-Wesley, 2000.

[Beck and Cunningham] http://c2.com/doc/oopsla98/paper.html.

[Beck and Fowler, 2001] Beck, Kent, and Martin Fowler. Planning Extreme Programming . Boston: Addison-Wesley, 2001.

[Boehm, 2002] Boehm, Barry. "Get Ready for Agile Methods, With Care." IEEE Computer 2002; 35(1): 6469.

[Boehm, 1981] Boehm, Barry, et al. Software Engineering Economics . Englewood Cliffs: Prentice Hall, 1981.

[Brooks, 1995] Brooks, Frederick. The Mythical Man Month . Reading: Addison-Wesley, 1995.

[Coad, 1999] Coad, Peter, Eric leFebvre, and Jeff DeLuca. Java Modeling in Color with UML . 1999.

[Cockburn, 1997] Cockburn, Alistair. Surviving Object Oriented Projects . Reading: Addison-Wesley, 1997.

[Cockburn, 2001] Cockburn, Alistair. Writing Effective Use Cases . Boston: Addison-Wesley, 2001.

[Cockburn, 2000] http://c2.com/cgi/wiki?PrettyAdventuresomeProgramming.

[Cockburn, 2002] Cockburn, Alistair. Agile Software Development . Boston: Addison-Wesley, 2002.

[Cockburn and Williams, 2001] Cockburn, A., and L. Williams. "The Costs and Benefits of Pair Programming." In Succi, G., and M. Marchesi, Extreme Programming Examined . Boston: Addsion-Wesley, 2001.

[Constantine, 1995] Constantine, Larry. Constantine on Peopleware . Englewood Cliffs: Prentice Hall, 1995.

[Coplien, 1995] Coplien, J. and D. Schmidt eds. Pattern Languages of Program Design . Reading: Addison-Wesley, 1995.

[Crocker, 2001] http://www.xp2001.org/xp2001/conference/papers/Chapter15-Crocker.pdf.

[Cunningham, 2001] http://c2.com/cgi/wiki?SystemofNames.

[DeGrace, 1990] DeGrace, Peter, and Leslie Stahl. Wicked Problems, Righteous Solutions . Yourdon Press, 1990.

[DeMarco, 2001] DeMarco, Tom. Slack . New York: Broadway Books, 2001.

[Fowler, 1997] http://www.martinfowler.com/articles/thud.html.

[Fowler, 1999] Fowler, Martin. Refactoring . Reading: Addison-Wesley, 1999.

[Fulton, 2002] Fulton, Hal. The Ruby Way . Indianapolis: SAMS, 2002.

[Gabriel, 2001] http://www.dreamsongs.com/LessonsFromNothing.html.

[Gamma, 1995] Gamma et al. Design Patterns . Reading: Addison-Wesley, 1995.

[Gause, 1989] Gause, Donald, and Gerald Weinberg. Exploring Requirements: Quality Before Design . New York: Dorset House, 1989.

[Gilb 1988] Gilb, Tom. Principles of Software Engineering Management . Reading: Addison-Wesley, 1988.

[Green, 1997] Available at http://www.mindprod.com/umain.html.

[Highsmith, 2000] Highsmith, James A. Adaptive Software Development . New York: Dorset House, 2000.

[Humphrey, 2001] Humphrey, Watts S. "So Why Don't They Practice What We Preach?" Available at http://www.sei.cmu.edu/publications/articles/practice-preach/practice-preach.html.

[Hunt, 2000] Hunt, Andy, and Dave Thomas. The Pragmatic Programmer . Boston: Addison-Wesley, 2000.

[Jackson, 1995] Jackson, Michael. Software Requirements and Specifications . Reading: Addison-Wesley, 1995.

[Jeffries, 2001] Jeffries, Ron, Ann Anderson, and Chet Hendrickson. Extreme Programming Installed . Boston: Addison-Wesley, 2001.

[Jeffries and Hendrickson, 1998] Jeffries, Ron, and Chet Hendrickson. Chrysler C3 Payroll . Smalltable Solutions, 1988.

[Jones, 1994] Jones, Capers. Assessment and Control of Software Risks . Upper Saddle River: Prentice Hall, 1994.

[Kaner, 2002] Kaner, Cem, James Bach, and Bret Pettichord. Lessons Learned In Software Testing . New York: Wiley, 2002.

[Kidder] Kidder, Tracy. The Soul of a New Machine . London: Penguin Books, 1982.

[Leuf, 2001] Leuf, Bo, and Ward Cunningham. The Wiki Way . Boston: Addison-Wesley, 2001.

[Marick, 1998] Marick, Brian. "Testing Foundations." Available at http://www.testing.com/writings/automate.pdf, 1998

[McBreen, 2002] McBreen, Pete. Software Craftsmanship . Boston: Addison-Wesley, 2002.

[McBreen, 2000] http://www.computer.org/Proceedings/tools/0774/07740421.pdf.

[McConnell, 1996] McConnell, Steve. Rapid Development . Redmond, WA: Microsoft Press, 1996.

[Morales, 2002] Morales, Alexandra Weber. "Going to Extremes." Available at http://sdmagazine.com/documents/sdm020la/020la.htm.

[Nonaka, 1995] Nonaka, Ikujiro, and Hirotak Takeuchi. The Knowledge Creating Company . Oxford: Oxford University Press, 1995.

[Pavlicek, 2000] Pavlicek, Russell. Embracing Insanity: Open Source Software Development . Indianapolis: SAMS, 2000.

[Raymond, 1999] Raymond, Eric. The Cathedral and the Bazaar . Sebastopol: O'Reilly, 1999.

[Reeves, 1992] Reeves, Jack. "What Is Software Design?" 1992. Available at http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm.

[Rollings, 1999] Rollings, Andrew, and Dave Morris. Game Architecture and Design . Scottsdale: Coriolis Technology Press, 1999.

[Schwaber, 2002] Schwaber, Ken, and Mike Beedle. Agile Software Development with SCRUM . Upper Saddle River: Prentice Hall, 2002.

[Spolsky, 2000] Spolsky, Joel. "Things You Should Never Do, Part I." Available at http://www.joelonsoftware.com/stories/storyReader$47, 2000.