Slashdot Mirror
Extreme Programming Refactored, Take 2
Where I'm Coming From I've worked on several large projects (and innumerable small ones) as programmer and/or system designer. I thought long and hard about shelling out my $30 for this book (list price is $39.99, but you can find it for less online), and more importantly, scheduling the time to read it. I pride myself on being a software engineer, concerned with not just cranking out code, but overall system design. On the other hand, after being subjected to various overkill design methodologies, such as full-on UML, I'm wary of things that keep you so busy designing and reading books on the subject that you never get around to doing anything. One of the authors of this book (Rosenberg) is a big UML advocate and has written at least two books on the subject, so I was suspicious.
I want to like XP because I feel strongly about several of XP's source tenets -- such as frequent releases, not bloating the code right now with reusability that will never be needed, refactoring often, and unit testing. And of course it looks sort of 'open-sourcey.' Power to the programmers! I finally decided I had some time to spare, so I lined up Extreme Programming Explained by Kent Beck, Extreme Programming Installed by Ron Jeffries, and XP Refactored.
The Outline XP Refactored starts out by examining eXtreme Programming's basic methodologies and its central claim: In other methodologies, making changes to the project takes exponentially more resources the further along you are in the project. If you make a big change after two years of development, it costs a lot more than a big change after one month of design. XP's basic claim (even if they don't enunciate it this way very often) is to flatten the cost of change by keeping everything in a state of flux all the time. In their words, Embracing Change.There are 12 canonical XP Practices, and a couple more which weren't part of XP originally but are now gospel, such as collocating -- the entire team needs to fit in one room, or some of the Practices break down. The book goes through the four values, the four activities; basically you get XP in a Nutshell right up front. And the authors do a good job of presenting these in the spirit intended, I think -- after reading this chapter you might feel that XP is a fine thing.
Then we start getting into the juicy bit you bought the book for. They start by examining the infamous C3 project at Chrysler. This was the poster-child XP project that launched XP to stardom and spawned a flood of magazine articles and 20 books on the subject. It was started in 1996 as a payroll system to replace the payroll system running on Chrysler's mainframes, because Chrysler was pretty sure that the Y2K bug would cause all their mainframes to keel over on Jan 1, 2000. Kent Beck was brought in, and he brought in the others. The project was canceled in Feb 2000, when it was apparent that it was still nowhere near done and the mainframes were still working after the drop-dead date.
This chapter really sets the tone for the book. First, we get the too-clever-for-my-taste Beatles filks (song parodies). We get a fairly concise summary of what happened along with references for you to study if you wish. We get lots of satire from the authors. We get copious quotes from XP gurus hanging themselves with their own rope -- and this proves to be one of the most powerful techniques in the book. You are given all the URLs you could ask for to further research the subject yourself, including the XP gurus' own takes on what happened. You will learn that to XP people, 'inexplicable termination' of a horribly late project that has failed in its very reason for existence can be Success. It is at this point that, if you love XP, you will probably fling the book against the wall and walk away. As gleeful as the XP camp was in trumpeting the early successes of the C3 project, the authors of XP Refactored are just as gleeful in dissecting the final outcome and the subsequent confused disarray in the XP camp -- such as TerminationCanBeSuccess.
The next chapter, 'The Case Against XP,' provides the manifesto for the book. It lays out the authors' case in a step-by-step overview. You won't be convinced of anything after reading this chapter, but it summarizes and provides references to later chapters.
'Extremo Culture' examines what kind of people are attracted to XP, how XP plays on the natural inclinations of most programmers who will be attracted by some of the good ideas and not-so-good ideas XP builds on, and the XP culture of fear. XP is obsessed with Fear and Courage -- you must have Courage to do XP, and if you oppose it, it's because you're Afraid of it. You need to be corrected or eliminated (off the team, nothing more violent than that). The only thing that causes project failure is Fear - either you were afraid of XP and weren't doing it right, or someone outside was Afraid of your XP project. I found this chapter quite fascinating, because I could see a lot of myself and the people I've worked with in it.
Having laid out the Practices, and The Case Against XP, the book takes on each of the practices in turn and gives it a thorough going over. This is the largest section of the book, as there are 12 (plus) Practices to cover in detail. The outcome of the analysis is generally negative, though not always -- the authors feel that XP's emphasis on unit tests is a good thing in general and should be expanded to other methodologies. They like frequent releases, just not quite so frequent. The Pair Programming chapter is perhaps the most gleeful, because it's arguably the worst idea in eXtreme Programming when taken to the eXtreme of no programming alone, ever, so there's plenty of fodder for wit and demolishment. But they also examine how Pair Programming is part of the Practices because it's required to compensate for other XP fragilities. This chapter is available as a sample chapter on the authors' website.
After examining the Practices, the book looks at the outcome of another XP research project: what would you expect to happen based on the previous chapters in the book, what did the study report show happened, and what can we learn from this? The predictions of the XP Refactored authors seem to be mostly borne out, and of course they say this proves XP is a bad idea. Though in the end, the study authors said, "But we liked XP anyhow." So you can draw your own conclusions on this one.
And finally, in perhaps the most practical chapter, they take XP and Refactor or 'defang' it. XP makes use of some good ideas, after all. The major failing is taking them all to extremes on the theory that if chocolate tastes good you should eat nothing but chocolate (You think that's silly? Beck reasons exactly this way.) This chapter suggests how to combine XP with real software engineering practices to hopefully achieve manageable, predictable results. Combine flexibility with actual design and risk control. Perhaps not surprisingly, this method resembles a lot what you'll often find small teams of skilled programmers doing on their own. And if you asked them what methodology they were using, they might even say eXtreme Programming, even though they aren't.
What Doesn't Work? Let's start with the bad. The song parodies are unrelenting and painful. If you like filking for the very idea of delicious subversion of media to your own ends, or you are the kind of person who loves any web comic that mentions Star Wars simply because it mentions Star Wars, you may think these are clever. At least they're easy to skip, but severely hamper the utility of handing this book to a manager and saying, "Please read this, it's important." The prose satire sequences and Monty Python skits are less painful, but again often too self-satisfied for their own good. But sometimes nothing makes your point like satire.If you're a big XP fan coming in, you will almost certainly be turned off by the relentless skewering of XP. Then again, I don't think this book is aimed at you, nor is this review.
XP Refactored does an excellent job of providing all the ammunition you will need to convince anyone who might be thinking of foisting pure XP on you that it's a bad idea, even in manager terms. However, it doesn't provide an 'executive summary' chapter and it could definitely use one - simply because no manager is going to read through this entire book, much of which is in programmer-speak. Chapters 2, 3, 14 and 15 all almost fit the bill, but it needs one chapter with references you can just rip out and hand to your boss to read between holes of golf.
What Works?Advocates of a position usually fear the other side, and will try to prevent you in some way or another from being subjected to the opposition's best arguments. On the contrary, the authors of XP Refactored seem to feel that the more you read about XP, in the words of Extremos themselves, the better their anti-XP case is made for them. Quotes are used relentlessly, and by the end of the book you will have the eXtreme suspicion that most of the XP authors are making everything up as they go along with no worries about consistency. Which, if you think about it, is pretty XP -- all the contradictory injunctions can be refactored later. Very often the authors' best case against XP is made by a prime quote from an advocate, with reference supplied so you can go verify that it's not out of context, of course.
Secondly, there are frequent Voice of Experience sidebars, which consist of feedback from people who have been involved in XP projects. The authors say they did not solicit these, but when word got out that they were doing the book they started getting submissions anyhow. They delayed the book and added 25 pages in order to fit the VoXP sections. That was very smart, because these notes from the field are quite visceral and provide powerful contrasts between XP in theory and XP in practice -- simply reading the authors' arguments would not be nearly as convincing. For example, the field stories of how XP coaches or managers tend not to do Pair Programming, even while they make everyone else do it, because they hate it too.
XP Refactored is not relentlessly anti-XP, though it sure may seem like it at first blush. The authors do a good job of presenting XP ideas in terms that are not unflattering before they dissect them. They do acknowledge that many XP practices are just good ideas that have been 'turned up to 11' on the theory that more is always better, and will point out the core of a good idea. For instance, rapid releases are a response to the problem of massive unwieldy design methods where everything is supposed to magically all come together at first delivery way down the road, and often doesn't. They also point out that most of XP is a pretty good mode in which to maintain already developed and mature software.
This book makes an important distinction between two levels of XP - the 'official' XP, which is what you'll get in the books (though that's often contradictory) and the 'Extremos' position, which is what you get when the authors argue amongst themselves on Usenet or Wiki and are less guarded and more honest. This is an important distinction as far as theory vs. practice. You'll glean from the various quotes and URLs, if you haven't read the XP books, that Kent Beck is a fairly intelligent guy and knows when it's smart not to go into too much detail on a delicate subject, and when it's time to move on to other causes like Test Directed Development. And then you've got people like Ron Jeffries and Robert Martin who should be thanking their personal gods every day that XP came along and gave people as horribly unqualified to manage or design software a bandwagon to hook onto.
I was a bit harsh earlier on the song parodies and satire sections, but in many cases humor is used quite well to expose the underlying weaknesses or contradictions in XP. That old British humour serves its purpose, and should be well received by the geek audience for the most part. Do you like User Friendly? You should love this.
Finally, the book does an excellent job of clarifying the cultlike nature of XP. How it appeals strongly to coders who think they're being oppressed by The Man and claims to empower them while reducing them to a commodity. Anyone who opposes the culture it is Afraid of you, and needs to be eliminated (non-violently) or ignored. If your XP project fails, it is because you weren't Really Doing XP - any deviation from XP is what lead to disaster. However they'll also tell you it's so flexible you can feel free to change it in any way to fit your way of working. Except you must always Pair Program. Except when you don't. Got that? You may think I am stupidly oversimplifying here, but no, quotes and references are provided. And I'd already gotten a lot of this just by reading two pro-XP books (XP Explained and XP Installed).
Key PointsIf you are already pretty sure you want to read XP Refactored, you may want to just skip this section. These are key points I got from reading the book, and of course they're made in far more detail and more cogently in the book itself. This is where you'll find it's pretty clear that I ended up siding with XP Refactored, as well.
The most important argument XP Refactored makes, and uses as a basis through the rest of the book, is that XP is a highly fragile web of high-risk practices which are woven in a tight web to minimize the damage from the other bad practices. These are (mostly) worst-practices that coders engage in because, heck, the most fun part of programming is the coding. So XP attempts to compensate for them and turn them into virtues. For instance, the lack of written documentation is balanced by the code sharing and pair programming, which are supposed to make sure that everyone knows everything about the system. If any one of the practices is not followed religiously, the whole thing comes crashing down. This is referred to as the 'circle of snakes' and is an excellent distillation of what XP books continually hint at but don't tell you outright. XP Refactored goes through each Practice and shows how failing to stick to it causes everything else to collapse, domino-like.
The circle of snakes means that XP (and this is my own analogy, don't blame the authors) is a precariously controlled free-fall, which should get you to where you want to be faster than hiking if you can maintain control. But people don't stick to the practices 100%, because they're very high discipline, the circle unwinds, and the snakes are venomous. As usual in the book, this viewpoint is validated by plenty of quotes from the Extremos themselves, who will tell you that any XP project failed only because you deviated from XP. And XP is such a high discipline methodology that unless you are continuously coerced back onto the true path, you will deviate from it; this is also covered in the C3 chapter, where it happened to even the Poster Child XP team.
XP's indifference to design is pretty astounding to anyone who's gone through any reasonable sized project. The theory is that you don't add anything more than you need at the moment. YAGNI (You Ain't Gonna Need It). And to a certain extent this is a good idea - if you're writing a small memory pool system, there's no need to turn it into a full blown memory manager 'just in case'.
But to use an XP example from the book, if you're working on an program that will need to work with objects on several different systems (local disk, database, web, ftp) but right now you're only got the disk based story card (user stories being broken up into small tasks) you hard code everything in your program to go right to the disk. Even though you know that you will need web support, because the customer insists on it, you are not allowed to plan for that whatsoever by adding a layer of abstraction between your code and the abstracted 'object holder'. Rather, when someone needs to add web support, they will just code it right in, maybe at least out in a separate web class. It will have a slightly different interface than the disk class, since there's almost no design, no planning, and different people coding it. Then later on you will refactor the code and merge these three or four different systems, make them behave the same, and clean up the code.
This is incredibly expensive and error prone for something that could have been avoided with even a little thought up front. You can say that any decent programmer would of course realize this was what was needed to be done, and add the abstraction layer. But you are no longer practicing XP. You made it needlessly complex for the moment, and added a requirement that might be removed.
There is no need for any large scale design in XP because it will naturally 'emerge' from continuous refactoring. As Kent Beck says, "The larger the scale, the more you must rely on emergence." You can treat a 10,000,000 transaction per second system as if it were a 1 transaction per second system. You write the 1 tps system, then the 10,000,000 tps system will just be 'refactored' from the 1 tps system when necessary. You don't need to worry about degenerative interactions between different parts of the system. You don't even need to worry about any error handling or out of bounds cases because that's not simplest possible design, until the customer codes up acceptance tests that trigger these. If you've been on a real project you're probably gasping for air now.
These next few points are points you can bring up with your management if they decide to do XP since they read a neat article about it somewhere. I know arguments that appeal to management aren't necessarily going to be seen as a good thing by coders, but if you've had some project experience they should make you break out in a cold sweat too.
An incredible burden is shifted to the 'customer' in eXtreme Programming. The customer (representative), in the room at all times, is responsible for expressing all the requirements in the form of short use stories (which can be jotted down on a card) and in the form of code, as acceptance tests. The customer is now responsible for everything, and if anything doesn't work, it's the customer's fault for not making their tests stringent enough. Given the extremely low likelihood that anyone is going to dedicate a senior designer/programmer to work with the XP team indefinitely, this tends to fall on someone more 'expendable'. Who is still expected to do a massive amount of work and know how to code and take all the responsibility for the project while having no real authority over the XP team that's implementing it. It should come as no surprise that this is a high stress, high burnout position and that the XP people are trying to 'refactor' this requirement constantly. Now ask your manager who the 'customer' is going to be.
Excellent management ammunition also comes in XP's total inability to deliver your requirements on time - it's quite up front about this. This seems a little strange for something that claims to make your development more rapid, but one set of XP gurus will tell you that XP can deliver by a fixed date, but not a known set of deliverables, and another will tell you that XP can deliver any fixed set of deliverables, but not by a known date. Which works out to be equivalent. Other methodologies often deliver late, but XP doesn't even try, and this is because XP totally punts any real design or scheduling. You can't tell how much emergence or refactoring it's going to take. Let's hear it in their own words:
"One of the most important principles in planning for Extreme Programming is that the dates are hard dates, but scope will vary.'" -- Kent Beck and Martin Fowler.
"There is a difference between 'Schedule' and 'The Schedule'. In XP, 'Schedule' is very important, but 'The Schedule' doesn't exist per se. ... The reality, of course, is that a software project is never done until it has been terminated." -- Robert C Martin
"Once you accept that scope is variable then suddenly the project is no longer about getting 'done'. Rather it's about developing at a certain velocity. And once you establish a velocity then the schedule becomes the customer's problem." -- Robert C Martin
My favorite quote in the whole book also comes from Robert C. Martin:
"If you lose a card, and if the customer does not detect that loss, then the card wasn't very important. If, however, at an interaction planning meeting, the customer says: 'Hay [sic], where's that card about blah, blah, blah,' you'll find it easy to recreate."Did you get that? It's okay to drop customer requirements in the trash, and unless the customer remembers to code up an acceptance test checking that requirement... the joke's on him! The customer can request you do some documentation, any documentation, monsignor please, only by writing up a story card - how often do you think those get lost? And lest you think this is just a moment of weakness, XP Refactored supplies other quotes from XP gurus encouraging you to dink with the user story cards as it suits you. Summary
XP Refactored largely succeeds in the task to which it set itself: countering the hype of XP, or at least defanging it and making it sane. It won't make any difference to the fanatic adherents and their book empire, but this is an excellent guidebook if anyone tries to foist XP on you, or if you'd been making sideways glances at XP, curiously attracted as it batted its eyes at you. You can tell they had fun writing it, so it's mostly a fun read.
It could sorely use an executive summary chapter consisting of only the most compelling points with references, and please, no humor. For giving an executive to read when you're threatened with XP since he read about it somewhere.
Now I know people are going to read this and indignantly retort that XP is based on some good ideas, and I fully agree. XP's starting assumption, as explicitly stated by Kent Beck, is that if a little of something is good then as much of it as possible is even better. I like chocolate, but I'm not going to eat to exclusion. I further know people are going to respond 'But XP doesn't require you to _x_!', where _x_ is something like lack of design, or not planning ahead. This again is part of the cultlike beauty - you can claim any conflicting interpretation of the Rules you want. The primary advocates often do - Robert Martin says You Must Pair Program, Ron Jeffries says it's an ideal only, except where he says it's absolutely required, but if you fail then it's because you deviated from pure XP. Is that a little breathless? Well, no wonder.
XP Refactored really clarified my uneasiness with XP after reading the two XP books - first it simultaneously devalues real software engineering by providing justifications for ditching it all and treating programmers as commodity items. Secondly the horribly risky practices, combined with the incredible hype, seems to be setting us up for a return to crushingly restrictive, mind numbing waterfall methodologies when it shatters in the field like the fragile flower it is. As already happened at Chrysler, where even Smalltalk and the concept of Object Oriented were tarnished by association with the C3 project.
If you find yourself drawn to XP, as I was, I suggest you read Extreme Programming Explained, by Kent Beck, then this book. Hopefully you can read these and come away with a good idea of what works in XP and what doesn't. Perhaps you might feel the urge to unit test a bit more. Or do rapid release with at least some sane amount of design. Frankly, I got a better feel for the actual strengths of XP from Refactored than I did from any of the pro-XP books, including Explained. Which is pretty good for a book whose stated purpose is to deflate XP.
You can purchase Extreme Programming Refactored: The Case Against XP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I think extreme programming has been always there in form or another (just like evil). It is just the buzzord (i.e. XtremePrograming) that is creating all the hype.
Consensus is good, but informed dictatorship is better
So in other words, you where not extreme programming. You where just wasting time and CALLING it extreme programming. This is like saying that driving a car to work dosn't work becuase you just sat in your driveway drinking beer.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
In any field, you have a set of "best practices" that describe how best to go about solving problems in that field. Intelligent people don't argue so much about these best practices, or at least don't fight over them zealously, because each principle is either obviously flawed, obviously correct to the best of our knowledge, or obviously has some measure of merit. An intelligent, honest, and experienced person can consistently separate each practice into one of those categories.
The fact that XP needs to make up a new word, "eXtreme Programming", complete with a capitalization error as though written by some half-d00d half-suit hybrid, and the fact that XP has to package a bunch of practices into one should tell you, before you have examined the practices, that the people behind it aren't interested in an intelligent, full and honest understanding of the best practices for computer programming.
My humble proposal is that we ignore these people.
Upstairs Dog, Downstairs People.
The more I program, the more perfectionistic I get. When I was younger I would just start coding willy nilly because I didn't know what to avoid. I would just write and debug until something worked for me in the obvious cases. Nowadays I find myself thinking and thinking about every possible tangential issue I have ever encountered in an effort to avoid any possible future mistakes. Sure I write way better code, but it also takes me a lot longer.
I think XP is partially inspired by a desire to recapture that youthful productivity (ignorant though it may be). Sometimes overthinking a problem can become paralyzing, and it actually is more efficient just to code it the first way that comes to mind then fix it later. So even though I have no real interest in XP per se, I definitely see the justification for a lot of the concepts.
But I think the point is that this always happens. No one who tries to follow XP is able to fully follow its tenets, and then their failure is blamed on not following XP, just like you're doing.
I'd rather be lucky than good.
So while I am not a big fan of the total XP package, this one is actually right on the money. If the customer can't do the acceptance test, who can?
To a large extent, as a developer, I can, and do. Sure, the customer's approval is itself the final acceptance test, but the customer is not going to appreciate missing and mis-features because they weren't explicitly spelled out. AFAIC, it's the developer's responsibility to figure out what the customer actually wants, by active questioning and other methods, because only the developer knows enough about software development to fully appreciate the engineering issues, and pragmatically, a doofus customer is going to be a doofus customer whether you play passive-aggressive head games with him or not.
All of this buck-passing misses the point in two ways. First of all, it's everyone's responsibility to serve the needs of the organization to the best of their ability -- be it a company, a university, a government agency, or an open source project. Sure, there will be people who won't, both in management and in development, but the impact of slackers isn't ameliorated by retaliating with more slacking. And secondly, from a purely self-interested cover-your-ass point of view, when a project fails, the hammer will fall on you before it falls on your idiot manager, if ever.
Anyone who thinks this is going to change is probably also wondering why they no longer get recess and nap time. Dealing with incompetent and clueless coworkers, poor organization, and unreasonable expectations is just part of life. You can either deal with it constructively as best you can -- which might or might not mean seeking another job -- or you can turn it into an adversarial and ultimately self-destructive situation.
Proud member of the Weirdo-American community.
I read that book first, and nodded my head. Then I started checking out some of the practices, and discovered that XP is actually pretty good. For example, pair programming seems to be able to produce the same results in about 55% of the time that one programmer would take, -->but with about 40% less software faults--. Not only does it get past the "9 women to produce a full-term baby in one month" problem, but with significant quality improvement. Just don't go overboard.
This is a perfect example of what the reviewer was talking about, which is taking a good idea and turning it upo to 11. You're totally correct that it's unreasonable for the customer to not support the developlment, and they have to take responsibility. Everyone who's ever worked in that sort of development knows the kind of mental anguish that last second or conflicting requirements causes. However, totally pushing that reponsability to the customer isn't correct behaviour either. There's ground in the middle that needs to be met. That, by the way, is how other professional industries work - the people you're contracting with are supposed to bring expertise to the table that you don't have (thats why you hired them, after all).
I'm cynical of the people who see it as a silver bullet that will solve all their problems. These are the same people who saw C++, Java and XML as silver bullets that would solve all their problems. Yes, I'll just wave my magical fairy wand and this technology will somehow make softare design easy and yet allow you to retain your six digit salary. This will happen shortly after the monkeys fly out of my butt.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I may not be a programmer nor care much about eXtreme programming, but this was still one of the best written book reviews I've seen on Slashdot.
Other people submitting book reviews should read this one first. Thanks Sarusa!
ÕÕ
The mention of XP "pureness" reminds me of what socialists used to (or may still for all I know) say about the collapse(s) of communism - "they failed because they weren't practicing 'pure socialism'."
A side effect of using XP is that its flexibility makes it impossible to blame the methodology when a project fails; that is, it always comes down to bad choices made by the team members, and all team members share the blame equally. Less competent programmers are afraid of this responsibility. They like the job security of being able to blame a rigid, outdated process or a single team leader when a project fails. If I was not confident in the my own ability or the ability of my team members, I would disparage XP as well.
If you can read this, then I forgot to check "Post Anonymously".
There is a specific type of "customer requirement" which is daft, trivial, probably useless to them from any "business use-case" perspective, and damaging to the overall project. These are often the result of whimsy inserted into requirements docs drawn up by the nontechnical, and followed with unreasoning precision when drawing together the spec.
Silently dropping these in the trash is often the best way to test if the customer really wants them.
So many of the nuances of XP have gotten lost here, it's very disheartening. Any methodology applied blindly will fail. Period.
Early work on XP emphasized the human element of introspection. The review sets up a strawman argument about the rigidity of XP that may be supported by the newcomers like "Uncle Bob", but was not there in the original form.
Originally, XP placed a lot of weight on continually asking yourself "Am I delivering value to my customer?" Followed by elimination of activities where the answer was "no". In other words, do more of the things that deliver value and less of the things that do not.
Another nuance that has been lost is the idea that there are projects and teams that should not use XP. Kent's first book had a whole chapter on when not to use it.
I've used XP in partial form, and it worked. I've used XP in full form, and it worked. The common denominator is that I had a team of creative, engaged, disciplined professionals working together. Such a team does not need a huge process to force them to do the right thing. It needs a set of common disciplines to unite them. This is what XP provides.
"Genius may have its limitations, but stupidity is not thus handicapped." --Elbert Hubbard (1856-1915)
Bah, this is called regression testing, and it was described in one book called "The Art of Software Testing" by Glenford J. Myers, which was published in 1978. *1978*! And that's probably not the first place it's shown up. The point is: Regression Testing ain't a new idea, so don't go crediting XP with it.
:)
Frankly, I think you misunderstand TDD. My understanding is that TDD also dictates that you write your test cases *before* you write your code. In this way, the tests are supposed to act as a formalized specification. Of course, one has to ask if this practice is really feasible, but I'll leave that for another post.
Well, not exactly a "failure". It appears to have been a project that was never necessary in the first place. Once management saw that nothing happened on January 1, 2000, they started wondering exactly what they had been spending all their money on - especially when they still didn't have a working system that would have solved the alleged "problem". It's a wonder that it took them as long as a month to cut their losses and stop the ongoing waste.
Our former CTO was in love with XP. [...]Velocity was one of those concepts used by our CTO to explain why he didn't have to work more than 4 hours per day.
People who like to spew bullshit will use whatever the hot topic is. That's not the fault of the hot topic.
Because it freed him from responsibility from things like designing with scalability in mind.
The way to do this in XP is to write "1000 people use the system simulateously" on a story card and then let the product manager decide when to pay for that.
When it comes up, it's just like any other story card. The product manager and the developers get together and make the acceptance tests, and then the developers do the thing until the tests pass.
If developers are scared that they don't know how to design for scalability, then they can ask the product manager to put that card in early on.
I would never use it for a new software product.
Which is, of course, your choice. But I've used it successfully for three new products. I think that's the best time to use it; getting an existing code base up to XP quality standards can be a long slog.
XP is NOT about making up for deficiencies in the quality of your staff.
It IS about leveraging your talented staff.
If you have no talented staff, then you are hosed wether you use XP or not.
...if you're working on an program that will need to work with objects on several different systems (local disk, database, web, ftp) but right now you're only got the disk based story card (user stories being broken up into small tasks) you hard code everything in your program to go right to the disk. Even though you know that you will need web support, because the customer insists on it, you are not allowed to plan for that whatsoever by adding a layer of abstraction between your code and the abstracted 'object holder'. Rather, when someone needs to add web support, they will just code it right in, maybe at least out in a separate web class. It will have a slightly different interface than the disk class, since there's almost no design, no planning, and different people coding it. Then later on you will refactor the code and merge these three or four different systems, make them behave the same, and clean up the code.
Okay, now I've used XP, and this overview seems to be both completely inaccurate and insightful at the same time.
It's inaccurate because if you're writing something to work on all those different systems it'll be part of the system metaphor (an explicit XP practice), so wouldn't be hardcoded as described by any sane programmer - but the comment is insightful as it shows how blindly following one particular tenet (YAGNI) of XP can lead to a contradiction with another (System Metaphor).
XP does not advocate no design, it advocates minimal design. It's a contradictory design methodology in this respect, as different people will tell you different things. If you don't like the idea of of not doing any upfront design, you can produce a system metaphor that acts as a design to keep you on course. What XP says is that you don't spend any significant time creating this design, and that there's no need for this to be a deliverable for the project.
The thing the customer should be asking themselves in the above situation is: "How important is this disk based requirement?" If it's the most inmportant thing as the example seems to suggest, what's wrong with the programming team putting in all of their effort into getting this requirement finished first, so that the customer will have a usable system in the minimum amount of time? Or should they add interfaces for all of the other stuff they're not programming yet, which may or may not be correct when (or if) they get around to programming those other parts?