XP debunked
XP has been around for long enough now that developers are almost at the stage of accepting it as a standard approach to software development. Lets face it, it sounds crazy and cool, and most important of all, it has a really, really catchy title. You could sell piles of horseshit if you were to just stencil the legend ‘Extreme Stuff’ on it. Somehow it seems cool, dangerous, and something your mother is unlikely to approve of.
The reality of XP is somewhat less extreme. It’s basically a bunch of interesting ideas which I think fail when confronted with the ugly mess known to the rest of us as real life.
For example, pair programming. Now, this is a great idea. However, I wish you the best of luck in selling this ‘service’ to your customers. Picture the conversation that might take place:
You: We’re going to pair program! We’re an XP shop. You’ll get two developers per workstation!
Client: Cool! Two for the price of one!
You
: Um, no. Two for the price of two. You get the productivity of one (plus the benefit of a supervisor) for the price of two.
Client: Thanks. I’ll go for another vendor who can provide me with two people with the productivity of…two people.
The next advice offered up by XP is to have the customer always available. Now, everyone agrees that communication with a customer, face to face, is extremely valuable. However, XP neglects to mention a sad but true fact of real life. The goals of the customer and the vendor are often quite severely misaligned. The customer wants to get the most bang for the buck, and wants to cram in as much as possible for as little expenditure (both financial and time) as possible to them. The vendor on the other hand wants pretty much the opposite; to deliver as little as possible for a maximum of profit. Figuring out what the customer wants is vital, but integrating him as part of your development team and having him see all the dirty laundry is likely to result in a less than highly impressed customer.
Next we have the frequest incremental release cycle. This might work well for open source (insert trite ‘release early, release often’ chant), but it is no panacea. More important is to define milestones and releases, rather than just churn out release after release. In any large project, your QA/UAT (user acceptance testing) folks will just burn out if you keep bombarding them with release after release.
Which brings me nicely into unit testing. Unit tests are wonderful things, and can provide a great deal of robustness and regression testing for a system. However, I’ve found that in real life, QA engineers will still always find a whole bunch of issues. UAT folks will also find their own set. Unit tests are NOT sufficient. In fact, the attitude I’ve seen lately regarding unit tests just shows how dangerous these can be. The perception that if your tests pass, all is well and you can release is fraught with risks.
Of course, the test first approach suffers equally. While it could be argued that it provides more clarity over a code-first approach, it suffers from many of the same problems. Just look over the changelogs for any number of open source java projects. Almost as much time is spent (wasted?) on getting unit tests up to date, functional, and well behaved as fixing the actual code itself. From personal experience I can say that I’ve spent many hours debugging test cases and trying to see why they fail when the code they’re testing seems to be perfectly functional. Test cases are code in and of themselves, and so are just as error prone and susceptible to bugs.
XP’s call to move people around is another one of those whimsical approaches. Sure, it’d be great if everyone on a team knew a bit of everything. However, this approach is just plain stupid with certain types of projects. Many projects require very specific in-depth domain knowledge, and shuffling people around such that chances are that most are moved away from their main areas of expertise is simply flushing talent down a toilet. By all means, avoid the bottleneck of having one developer be the sole repository for a particular subsystem and its inner workings, but moving everyone around willy-nilly is certainly just as problematic.
Of course, this is not an absolute case against XP. There are some companies out there who successfully and wholeheartedly adopt XP and live and die by it (ThoughtWorks, for example). I contend however that these are aberrations, and that XP as a complete software development approach will never become ‘mainstream’. It simply expects too much from everyone, and assumes that the ‘average’ developer is versatile, talented, experienced, motivated, and highly enthusiastic (see the previous blog entry, and extrapolate to see why so many developers like XP). This certainly seems the case at ThoughtWorks (they are a bunch of talented smart guys), but is absolutely not the case pretty much anywhere else.
August 25th, 2003 at 1:10 am
The only project I ever worked on that used ‘XP’ was based on the assumption from high-level management that this meant that we didn’t need project managers anymore. Right, we get the code-monkeys to hack code for a month without worrying about overall plans and what have you. But of course there was no pair programming (the assumption here seemed to be that if you do XP with single developer programming you DOUBLE your productivity). Yep, worked so very well I quit at the end of the first harrowing month.
What I DO love is finding a particularly tricky subsystem or piece of refactoring and hitting that with some XP…maybe only a couple of days, or even hours of work. You pair up, sit down, write your tests, code, test, refactor etc etc. Used this srategy to overcome some terrible performance limitations – a pair of us rewrote an entire subsystem in a couple of days and refactored most of the rest of the app. Prolly not technically XP, but still …
August 25th, 2003 at 7:56 am
You really ought to read Pete McBreen’s Questioning Extreme Programming as he goes into detail about when and where XP is actually applicable. The point is that neither XP nor any other methodology is universally applicable across all kilnds of organisations, projects and teams. Sometimes you’re better off using Scrum or Feature Driven Development or XBreed or even RUP.
As for Toby’s project is sounds like they were doing Pretty Adventuresome Programming (http://c2.com/cgi/wiki?PrettyAdventuresomeProgramming) rather than XP. It’s a common problem.
August 25th, 2003 at 9:14 am
It would be pretty stupid to tell a potential customer that two developers do pair programming results in having the productivity of one developer.
Because after all it’s simply not true.
If you do it well, two people doing pair programming
will be much more productive than having them work
by themself..
August 25th, 2003 at 9:34 am
Hear hear Bileblog,
While I’m not a total XP dissenter, you touch on two of the issues that I’ve always had with XP:
1. Pair programming – good developers are also often egomaniacs. I think it’s idealistic to assume that two egotistical developers will always program well together. What happens if they disagree about some aspect of design. Strong ego’s generally spell death for software projects I’ve been involved with. This is not to say that developers should work in a vacuum. They should always be communicating and ensuring everyone stays up to date on the overall design. I find pair programming does have benefits when it comes to designing/developing critical aspects of a system but I’m skeptical of its benefits as a permanent fixture. Finally, if your developers are equally talented, one of them is bound to spend a lot of time being bored to tears as the ‘typist’ fleshes out mundane but necessary aspects of the system.
2. Unit tests – I’ve always wondered, “who tests the tests?” As you say, unit tests are in and of themselves, code. I think unit tests are good, but having a complete test-first mentality just becomes wasteful and cumbersome in my mind. Write tests for the parts that are critical. A sound architecture will usually take care of the rest.
Anyway, all fodder for thought.
August 25th, 2003 at 11:48 am
For some fun regarding XP check out:
http://www.softwarereality.com/ExtremeProgramming.jsp
August 25th, 2003 at 1:23 pm
Hmmmm… some very interesting points. Many of these have come up in discussions with people at work in the last month or so.
I share your concerns on all points. I think the innevitable conclusion is that XP in its purest form is not a universal panacea. The key issue is buried in your remarks about ThoughtWorks. With a really good team you can achieve wonders with XP (an probably with other methods also), but with a mediocre team you will not (again, with this or any other method). No process can paper over lack of ability.
In terms of the applicability to different types of projects, one of my disappointments is the lack of evolution in XP (as far as I have seen anyway). By evolution I mean the transition from a method to a methodology – a toolbag of techniques which should be picked and mixed according to the constraints of the project.
One of the big things that comes up in any iterative method that involves partitioning into cycles is the idea of ranking the features in each cycle and then doing the ones that you have time to before moving onto the next cycle. This becomes very difficult if you are working on an internal project within a large organisation. It is hard to get the concept of optionality across to the users.
IT: “Which are the most important features?”
USER: “They all are”
IT: “Can you please rank them”
USER: “OK, as long as you deliver them all”
August 25th, 2003 at 3:40 pm
What I find intresting is that the key project, C3, was cancelled, see http://c2.com/cgi/wiki?CthreeProjectTerminated
If the experts can’t make it work, what hope does the average joe have?
August 25th, 2003 at 4:01 pm
Jeff, I think you missed the point as to why the C3 project was cancelled. It was not because it didn’t deliver on time, or on budget, or don’t deliver. It was purely for political reasons. All in all, when the project was cancelled they had a functional piece of code that was on production.
That’s a big constrast with projects that get cancelet without a single line of code going live.
From the development point of view, C3 was a success (on time, on budget, meet the requirements), but from the enterprise point of view is just another case of “This is what we wanted then, not what we want now”, that is, a failure.
August 25th, 2003 at 5:11 pm
I think rants like this one come from the fact that many programmers have never actually done XP or even been around someone who has.
http://www.blueskyonmars.com/archives/2003_08_25.html#000983
August 25th, 2003 at 8:30 pm
Personally I find XP a bit over the top for most projects, but when people criticise it, they usually miss the real problems it has and focus on the easy targets. The problem I have with XP is not XP itself, but how difficult it is to do right.
Pair programming works, but you need disciplined developers to make it work well. I mean, its true egomanics are hard to work with, but they’re hard to work with without pair programming. Its true that morons are hard to pair with, but they’re morons, whaddya expect? Pair programming works as it provides code-review and oversight, and communication and thought on design issues. Another thing people don’t realise about pairing is that pairs tend to spend a lot more time actually coding than when they are alone – its much harder to skive off and read your email/surf/irc whatever when you’re wasting someone else’s time. The last thing about effective pairing that people miss is that you shouldn’t spend 100% of your time pairing, and (I believe) there needs to be a second workstation for the pair (to research stuff, write tests etc.).
Unit tests aren’t easy to write, they’re boring, unglamorous, unsexy code and developers generally don’t want to write them – until they save their arse on some big feature addition where they’ve broken another part of the system unknowingly.
For me, the big problems with XP lie in making sure the the Customer’s contract is observed properly. This is hard (as pointed out) as the cutomer often doesn’t want to commit the necessary time, the developers can crap on about iterations and velocity and baffle the crap out of a customer without technical skills and a highly tuned bullshit detector, and what you end up with is that the customer doesn’t get what they want.
There are many ways to make XP fail, and they are well documented, it takes a team of great skill and discipline to make it work – but are these problems with XP, or with the morons trying to do it? Its a bit like a difficult piece of music, mosty people attempting it make it sound crap, but in the hands of a gifted performer the results can be beautiful.
August 26th, 2003 at 2:35 am
About customer presence, here’s something we do once in a while: since we are doing a product and not one-time consulting gigs, we sometimes offer customers to help us develop a specific feature that they need. They get to provide us with requirements and helps us with testing, and in return they don’t pay anything for it. Once that is done we can either integrate the feature in the standard product, or offer it as a for-fee add-on that other customers can buy. That way all involved are happy.
October 29th, 2003 at 3:46 am
I think we’re missing the point here. If the C3 project had been delivering real business value to Chrysler then it wouldn’t have been canned. If a project doesn’t deliver enough value then it has FAILED. Just because you delivered working code on time and within budget doesn’t mean to say that your project has succeeded. XP confuses velocity with productivity. They are not the same thing. If you’re climbing the wrong mountain at 100 ft per hour then your productivity is zero.
April 30th, 2004 at 2:59 pm
If the XP team is climbing the wrong mountain at 100 ft per hour, then the “customer” has pointed the XP project to the wrong mountain and given the wrong objectives. XP, as practiced at Chrysler, *required* the “customer”, i.e. management and/or domain users to be onsite and participating at all times. If the wrong mountain was being climbed, it was a political or otherwise short-coming – not an XP one.
July 13th, 2004 at 7:42 pm
oh, that’s alright then….
May 30th, 2008 at 8:23 am
Being afraid of wolfs do not go to the forest,