Far from being the next great thing in software development, I'm more inclined to think that Xtreme Programming is that bright flash that occurs just before a light bulb burns out. The group I am in follows many of the practices of Xtreme programming; while they are certainly worthwhile and probably better than other practices, their overall impact on our project has been modest. The central issues is that Xtreme programming is heavily focused on the code and the process of coding, including code design (as versus application design). That's not where major software development problems are today. 1. Determining the requirements continues to be the dominant problem in software development. It is the biggest cause of schedule slippage during development and the biggest cause of product failure after delivery. Great software architecture, terrific coding skills, and superb debugging ability are, at best, a weak defense against requirements changes. Xtreme programming has little to say on this front. A not often mentioned fact about the Chrysler payroll success story is that another group had already spent 3-4 years establishing the requirements. The Xtreme programming group only got their chance when management decided that the other group wasn't making progress - because no code was rolling out?. In fact, although phased development can provide early prototypes to show to users, Xtreme programming advocates recommend against showing prototypes to the users because it raises expectations!! 2. Even in the software development proper, the biggest problems today are probably in the area of installation and deployment, not in code writing. The "bugs" that crash telephone systems are not bugs in the code, but errors in the configuration data that are loaded into the programs. Similarly, the biggest problem in product support for my company are install problems; if it won't install, who cares whether it has bugs or not? Again, Xtreme programming considers deployment to be some else's problem. 3. Xtreme programming seems focused on "green field" development, writing a new program from scratch. This is a declining activity. Few corporations can afford the luxury of doing what Chrysler did and writing their own payroll program. Instead, most companies focus on acquiring and using an existing package for this kind of application. The job market reflects this trend. C++ programmers are a megadollar a dozen, but an Oracle or SAP consultant can command an annual salary in the six US$ digits. Certainly, it is possible to go to far in the opposite direction and totally neglect the software architecture and code in favor of contextual inquiries into user requirements, organizational deployment planning, etc. In this rare case, Xtremem Programming might well be project salvation. Ruven Brooks
