Xp Is Nota Silver Bullet

XP Is Not a Silver Bullet (see also NoSilverBullet)

A lot of people are expecting ExtremeProgramming to turn trained chimps into SuperProgrammers. Of course it can do no such thing. Like any other software process, XP requires:

A group of reasonably clever developers.
That those developers work together in good faith.
Sufficient domain expertise. That is, understanding of the problem domain (possibly via the OnsiteCustomer).
Sufficient technical expertise. That is, understanding of the techniques to be used in implementing project.

If your project is lacking one of these necessary conditions for success, then that lack is your problem, not your choice of methodology.

What can XP do? Well, even projects that meet all of the above criterion often fail. Maybe XP can help some of them succeed. --JohnBrewer

I saw this comment on the ExtremeHumility page:

: Even an XP cynic like myself (sorry, I've seen too many silver bullets wizzing by in the past 40 years to jump on even inviting band wagons) can see the wisdom of what you say.

I'm aware that I'm attaching way too much precise significance to what was probably a throwaway comment, but I think the questions should be asked and answered: Is XP a silver bullet? Does it even claim to be?

From what I can tell, the answer to both questions is "No." XP's adherents and practitioners claim that it is an improvement over other processes that they've used, but that raises the question: what is being improved, and by how much? Are XP teams more productive? Probably, but not by anything close to an order of magnitude. Are they more reliable? Simpler? These are harder questions, at least in part because Brooks' precise meaning (see NoSilverBullet) is open to debate. My interpretation is that he's referring to the software development process itself, and using "reliability" as a measure of how often projects "succeed" (however that is defined) and "simplicity" as a measure of how tricky projects are to manage successfully.

By those definitions, XP's primary claim to silver bullet status would seem to be on the "reliability" front: XP claims to help projects succeed. But I don't hear anyone claiming a tenfold increase in reliability, or anything even close to it. XP may also have some significant, but not earthshaking, contributions to making projects simpler to manage.

If you feel that Brooks is referring to the simplicity and/or reliability of the software itself, then XP also claims to help in those areas, albeit (again) in incremental, rather than revolutionary ways.

-- GlennVanderburg

All of which raises yet another question: How does XP help? We've all seen a lot of discussion that seems to rest on the assumption that XP is good. But why is it good? What benefits does it really claim to have? The closest thing I've found is the page WhyXpIsPopular, and what I see there matches my understanding of things:

XP is more enjoyable (many of the other items in this list seem like contributors to this one)
XP is more honest, at least in the sense that you spend your time on things that you actually believe have value and provide honest, realistic estimates and progress reports
XP is more flexible, in that it leaves the team and the software open to changes of direction
XP provides control over several factors that tend to be big time-wasters on other kinds of projects (ever-changing requirements and political games such as ScheduleChicken)
XP is less stressful because you are not expected to predict the future
XP reverses the trend for software to decay and grow more complex over time

I'm sure there are more, but it seems clear that the goal of XP is not to be a SilverBullet, at least not in the FredBrooks sense.

--GlennVanderburg

As I recall, Brooks claims success partly because he separates what he considers different techniques. He'd consider reusable components, object orientation and better IDEs to be 3 failed silver bullets even if together they give you a 10-fold increase. I think he'd probably consider XP to be a collection of bronze bullets rather than a single silver one. -- DaveHarris

I'm new to the XP thing but an old fan of TomDeMarco's common sense and the common sense that says that small teams with clear objectives and talent get lots of good stuff done quickly. -- MartyHeyman

What do you do when you don't have A group of reasonably clever developers with sufficient technical expertise? Or worse, what do you do when you're on a team without said resources?

In all of my experience so far, a project that lacks decent developers also lacks success. Is there anyway around this aside from adding 2 years of training and practice to the schedule?

I've seen projects that I wasn't directly involved in succeed with incompetent programmers. They had a long development schedule which included massive BigDesignUpFront and testing on the other end. I can't say I liked their code, nor their documents, nor the execution speed, nor their continual schedule slips, but I've seen them produce programs that output the correct things for valid input.

I believe the practice of PairProgramming is meant to make the high-discipline/long experience needed parts more possible for novice programmers.