Here are some notes from my early XP investigation:
Extreme Programming (commonly called “XP”, an unfortunately overloaded acryonym with Microsoft’s impending release of Windows XP) is a relatively new, lightweight method for software development. I have been applying XP practices in recent projects with excellent results. There are a number of excellent web sites about XP:
http://www.xprogramming.com has a good general introduction.
Martin Fowler offers a concise description of the merits and mechanisms of Continuous Integration, a core XP practice. There is also material on Continuous Integation on the WikiWikiWeb (mentioned below) here and here.
A common objection to XP is to call it “gloried hacking”, implying that XP does not value good design. Fowler addresses this issue in “Is Design Dead“. The short answer, towards the end of the article, is “Not by any means”. A higher-order answer to this objection is to note that many XP adherhents are people with quite strong design credentials.
A team at ThoughtWorks released Cruise Control, a tool for implementing automated builds for continuous integration. I have used Cruise Control with good results, and am looking for something similar to use in Delphi – Cruise Control works with Java and Ant. (If you need assistance getting Cruise Control or a continuous integration process working on your project, Oasis Digital offers consulting services.)
Is building and testing your whole product every day impossible, or ludicrous? I don’t think so, and apparently neither does Microsoft (a newer article has more details). If they could do it in 1996 with 5.6 million lines of code, it should be easy in 2001 with much faster hardware on a million-whatever lines of code project, right? Yet I have worked with groups who think of this as impossible on much smaller projects than that.
Another good source of insights on development processes including daily builds is Joel On Software. Joel does not talk about XP per se, but there are similarity between his recommendations and XP practices.
Pair Programming is probably the most controversial practice of XP. Many people (managers and developers) abhor the idea immediately upon hearing it. I’ve done some pair programming myself, and been pleased with the experience. It seems to work better in practice than one would expect. On the other hand, there are many programming tasks for which having two competent people working in parallel seems like overkill. A good starting point for information is pairprogramming.com.
Ward Cunningham’s WikiWikiWeb, though it has an odd name, contains a large amount of useful thoughts on XP, OO design, design patterns, and other related topics.
“Real” XP involves significant organization change, and buy-in (or at least acceptance) from many levels and parts of a company. Some of the practices, though, can appear quite radical, such that getting widespread adoption is difficult. Also, XP is not advertised as the solution to all problems. Even if your organization/project/etc. does not “go XP”, though, many of the XP ideas/practices can be applied in a not-really-XP environment with good results.