[Originally written in 2005. A little more polarizing than I would write it today.]
Extreme programming is a relatively recent software development process based on being “extreme”. Whether it will be thrown on the ash heap of history is unclear to me, but this essay is little concerned with that. XP is simply a process. It doesn’t ensure project success, nor does it guarantee project failure. Many of the negative reactions to XP are based in some disappointment over the individual principles involved. I don’t have particularly strong opinions on the principles and I suspect they range in value from highly effective to benign to mildly detrimental. But how those principles map to those values depends highly on the texture of the project they are being applied to.
Nevertheless, to me processes in and of themselves are not particularly interesting, so then why am I writing this essay? XP is a little bit different. Or more accurately, the advocates of XP are a little bit different. You see, the advocates are playing a game, preying on the misunderstandings between management and programmers to sell a product. The marketeers are no fools, they know what they’re doing. And the results of their actions are unlikely to be more successful projects, but instead fatter pocketbooks.
The Tenets of XP
Depending on the exact flavor of XP you’re buying, it comes with a dozen
or so core tenets. None of the tenets were invented by the XP marketeers,
but they were cannily put together. Here is a mostly representative list
of the core XP principles:
- On site customer
- Plan software iterations for ~2 weeks
- Automated Acceptance Tests
- Frequent Releases
- Simple Designs/No upfront Frameworks
- Pair programming
- Thorough Unit Testing
- Continuous Refactoring
- Continuous Integration
- Collective Code Ownership/No Specialization
- Coding Standard
- Develop a System Metaphor
- Not Too Much Overtime
All of these practices probably independently predate extreme programming. That is none of these ideas are new in and of themselves, so why were they combined into extreme programming? The naive answer is that they improve the odds of project success. In fact there is no credible reason to believe that more than two or three of these principles have much effect on project outcome whatsoever. Only one of the principles has truly persuasive empirical studies. Two more of the principles have fairly flawed studies in their favor, so while not proven best practices, they are likely fair to OK practices.
I’m being intentionally vague in my description of the values of the individual practices, again I just don’t think its that interesting. Instead I would like to look at the practices from a high level. Fully ten of the practices concern how a programmer goes about his daily business:
acceptance tests, frequent releases, simple design, pair programming, unit testing, re-factoring, continuos integration, collective code ownership, coding standard and limit overtime. Of the remaining practices, on site customer, and 2 week iterations primarily impact the developer. That leaves the system metaphor as the only activity significantly impacted by project management.
So then what conclusions can we draw from this list of principles? It is at this point that you must decide whether you agree with me, or you think I’m full of hogwash. What do you think the division of principles means? Spend a few minutes to think to yourself, and then read my interpretation.
- For my money, the implication is pretty clear. The XP process is mostly concerned with how programmers go about their daily business, and by corollary, XP must believe that how programmers go about their daily business primarily dictates project success. If you agree with me on that, then I think its an easy step to conclude then that XP is probably not a major factor in project success. You see, project success is primarily dictated by project management and the technical competence of the programming staff. Further, one of these items alone virtually ensures project failure, only with a substantial amount of technical skill *and* adequate project management can a project achieve even moderate success.
For most programmers, the parameters that I’ve stated for success are probably pretty easy to accept. Some other programmers may believe that pure technical competence can overcome bad project management (I doubt anyone thinks good project management can overcome bad programmers — bad programmers are simply a nonstarter). That’s fantastic, and I’m not here to trounce on the opinions of confident programmers. But for those of us that have successfully built the wrong thing, its pretty clear we have to know what to build, in order to build it.
So then is XP bad?
Certainly I don’t think XP is bad. Further, I think that at least some of the advocacy for XP is from programmers who enjoy XP. Nothing wrong with that. Unit testing is undoubtedly good, and pair programming can be fun, so I see no problems with adopting XP. My argument thus far is solely on how XP impacts project success. Hopefully, I’ve convinced you that it impacts project success very little.
So then what is bad?
In short, silver bullet salesmen are bad. Bad for the industry, bad for projects, bad for companies, and bad for you, the working programmer or project manager. You see, project managers are in a difficult position. Generally, they don’t know how to achieve project success — sometimes because they screw up by accident but somtimes because success is truely
impossible (e.g. unworkable budget or time constraints). Whatever the case, we still must consider human nature. No project manager believes that he is the problem. Therefore the problem must be the technical staff. XP allows the manager to tightly control the programming staff while requiring very little changes of the already adequate project manager. Of course managers
love XP. Agile is often a euphemism for managerial whim. And limiting overtime, managers and programmers often have very different expectations on how much overtime is too much. We all know who’s vote really counts.
So then my point is simple, XP is mostly orthogonal to project success.
It mostly has a large impact on its advocates pocketbooks, who are
preying on the fears and confidences of project managers. The next time
someone advocate suggests XP to you, hopefully you’ll be armed with the
insight to recognize that they aren’t selling success, they’re simply
advocating more regimented programming practices. It’s neither here nor
there, but they’ll be happy to collect a fee while showing it to you. I
begrudge no man his daily wage, and if that’s how the inventors and
advocates of XP want to make a living, I simply suggest: Buyer Beware.
I want to make sure and clearly state my argument one more time. I’m not saying that extreme programming is bad. Certainly chaos is worse. Nor am I saying that DOD processes, up front design, etc are better. Again, chaos is worse than these approaches as well. What I’m saying is that XP isn’t marketed on its merits, but rather its a product for sale. It has its costs and it has its benefits. It certainly does not ensure project success. Nor does it guarantee project failure. There is no silver bullet, but there sure are alot of silver bullet salesmen. Project success is primarily determined by the quality of your project management and the quality of your technical staff. Now please excuse me, I’ve got to see a man about a bullet.