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.
It's extremely long.
I was going to read this whole thing, but there was too much fecundity.
fecundity-The quality or power of producing abundantly; fruitfulness or fertility.
exTreme Programming, refactoring, man when I read this, the only thing that comes to mind is reducing equations while downhill biking on a 60% grade hill.
Someone please distill these ultra hyped buzzwords into something that doesn't sound like something from an ad agency selling sports drinks.
Extreme Programming = more than one person working on the same program.
The Truth About Slashdot
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
The parent was copied from here. Mod it down for plagiarism.
Who needs to buy the book, i read the whole thing in the article :)
-A
I mod down so you can mod up. Your welcome.
The word "eXtreme" makes me feel like I'm doing some thing atheletic.
I was involved in several programming projects which used XP. The problem is that the IT industry is filled with overweight dorks with hygiene problems and who lack social skills. So every time I was paired with another programmer, I was subjected to his body odors, immature comments (constant Microsoft bashing, etc.), and the constant crunch of Doritos. It drove me up the fucking wall. I am now a welder and I couldn't be happier. Mod this down if you want, but this is the honest-to-God truth.
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.
So you're telling me that the basis of extreme programming is a failed and cancelled project? live and learn i guess.
Sorry folks, but there is NO one right methodology that you can just take out of the box and apply to any project, small or large. And the relative importance of such things as design, unit testing, documentation etc., do vary. Of course coders don't like anything other than coding, but that doesn't make the other stuff any less necessary. The project requirements might, though.
How am I supposed to fit a pithy, relevant quote into 120 characters?
The two have a lot in common. They both look nice from a distance, but once you start using them, inexplicable thoughts of violence race through your mind...
Having said that, Windows has come a long way from the 9x series.
I am John Hurt.
But for some reason, business units think they can toss some poorly written requirements at a software team, "dedicate" a junior supervisor or even a junior secretary (seen it happen) at less than 25% of full time as the project representative, and expect to get a usable product back. Of course, when they don't it is the "techies" fault for having "poor communication skills".
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?
sPh
Extreme Programming is 1 step Up or Down, depnding on your view, from adhoc programming.
i have actually read up on the subject and do agree with some of the tenets of XP. however, i just can't bring myself to use the term "extreme" in regards to programming.
To me, it conjures up visions of fluorescent spandex, hang-gliding, and the superfluous use of the prefix "bungy."
It is always amazing to me how great the divide is between XP advocates and XP Cynics. The desparity between your post and the review is amazing, and in fact I get a similar separation of extreme opinions when reading any message board, articles, or even books for that matter.
What is it that is keeping programmers from reaching a consensus on this. Was Object Oriented design as controversial as XP is?
Is there anything more pointy-haired? eXtreme Programming.. eXtensible Markup Language.. Every time I see an X in an acronym my Buzzword warning goes off, unless it is something like Xylophonic Postamble or Xenophobic Mutant Litigation
The perfect sig is a lot like silence, only louder
yeah, yeah, check my spelling!
Take a problem, and two teams of similarly formed people, give them the same project, and see what happens. You make one team go XP and one go traditional.
I bet traditional would do better in this test because you'd need defined docuements to code. Now if you took those same two teams and gave them my boss (feature creep, no dev schedule, sells a feature before it's developed, etc), the XP team would live and the traditional programmers would be bald from pulling their hair out.
In development I've found you just go with the flow and try to keep your sanity.
Why can't the Extreme Programming crowd just call it Extreme Programming (or even 'EP') and not 'XP'?
Otherwise even ignoring the obvious confusion with WinXP, it makes it seem like the concept is being marketed by some lame-ass over-hyped sports drink company.
"It's programming... Xtreeeeeeeeeem!"
Here's one for them:
"Extreme Programming - It's slightly better... TO THE MAX!"
Nuff said!
"Extreme Programming Refactored Refactored"?
3rd Edition: "Extreme Programming Refactored Refactored Extremely Refactored"?
Chr0m0Dr0m!C
IMHO, the best overall programming methodology. Again, just an opinion.
What is your penile percentile?
on MTV.
/. article.
eXtreme Programming, followed by...the Osbournes.
Seriously tho'...what had me scratching my head about this the most was the fact that they actually used the word 'fecundity' in a
*walks away shaking head*
Don't park drunk, accidents cause people.
Too many notes.
Our former CTO was in love with XP. Why? Because it freed him from responsibility from things like designing with scalability in mind. XP works best in an institional setting where individuals are duplicating (or refactoring) an existing application or single purpose applications (say in a Fortune 1000 company). I would never use it for a new software product.
We retained a couple aspects of XP (namely unit tests) but chucked many aspects of the methodology. 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. Our board of directors got pretty tired of that after a while.
He no longer works here.
Thalasar
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.
Wow was that ever long-winded.
IMO, Some of the facets of Extreme Programming are great, but only as applied to organized process oriented programming. I strongly support working towards acceptance tests, however, I also strongly support up front design, so you know what you're supposed to code to. (The acceptance tests test the results, the design is the target). As for two people working together, only if one is a mentor, otherwise it's usually a major waste of resources.
The cesspool just got a check and balance.
The people that can program well will continue to program well. The people that need 'methodologies' and other tricks to detract from the fact that they write half ass code will continue to rely on anything that elludes to giving the impression that they can write anything other then half ass code.
If someone can program, they can program. they don't need any 'methodology'. If they can't program, they need to get out of the business. We don't need you. Go get into real estate or something. It's not our fault you wasted all that time trying to become a programmer. Get a grip on reality and give it up. It's that simple.
It's not hard to tell who these people are. Usually, they are the religous zealots who will argue methods til they are blue in the face. the minute you don't immediateley understand some minute detail above their obviously flawed 'methodology' they deam you stupid.
They say things like "you don't even understand what such and such is. how do you know it's failed?" well, that's about the weakest argument ever and I despise people that use it. I might as well go argue with muslim extremeists.
Anyways, extreme programming sucks, and I don't need to read a 15+ chapter book to know that. The paired programming concept, while not a new approach, is beneficial in only some circumstances. An actual circumstance is when some dork head programmer decided to use some object oriented derivitive 'methodology' and wrote 5000 line of code that only two well focused software engineers with a huge whiteboard could figure out after the dork head programmer got shit-canned.
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.
...It puts the burdon of decision on the customer( usually managment).
Show of hands: How man people have worked with a manger that would take responibility for decisions about every step of the program? hhmmm I see 1..oh wait he was just stretching.
The Kruger Dunning explains most post on
As Fred "Morpheus" Brooks said, "Don't try to find the silver bullet that will deliver bug free code on schedule and on budget.. instead try to realize the truth, there is no silver spoon!"
The perfect sig is a lot like silence, only louder
It's nice to see XP taken to task like this. Nice slap back at all the sophomoric zealots I've had to argue with about it.
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.
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?
Am I the only one who kept thinking of Windows XP when they were talking about "XP"? Windows "Extreme Programming".
I thought that was a decent review: definitely more informative that most of the book reviews they have here on Slashdot.
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!
ÕÕ
Wouldn't "XP Refactored" be the comming release of Windows for europe?
The problem is that XP works.
Well, in some situations anyway.
Not all situations, really.
Ok, only in some very specific environments, with specific types of programmers.
And XP has been proven by experience not to work in many many environments, and has a legion of programmers who have had bad experiences with it.
OO on the other hand was mostly only controversial because people cared about the performance hit. Most people thought it was a good idea, but not practical. Then the compilers caught up, and the hardware got fast enough, and the benefits of OO outweighed the penalties.
XP has flaws that are permanent and unfixable for many programming projects/environments.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
It's a book about buzzwords. It's virtually impossible to discuss this without using them.
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'."
..Alistair Crowley wrote the same thing about Magic(k)
So long as you perform it exactly right, it will always work perfectly. If it doesn't work, you didn't do it right, that's all.
Sorry, I don't have time for things that either work perfectly or not at all. If I get something 99% right, I want something that works 99% of the time, thanks.
That Jesus Christ guy is getting some terrible lag... it took him 3 days to respawn! -NJ CoolBreeze
And Lasers . . . its gotta have lasers. . .
I looked at the XP stuff, semi-digested it and rejected it as marketing hype. But one portion of the process I've really embraced is the automated testing. Called Test-Driven Development, the idea is that rather than writing a test to test the code you've just written (like you have to do regardless) and then throwing it away, you keep it, and also place it in an organized framework where it can be run again and again.
The upshot of it is that you're much les vulnerable to regression, or more precisely, that you can more readily see the effects. TDD is actually much more complicated than I've outlined here, but just search on JUnit (for Java developers) or NUnit (for Microsoft developers). Most of the big leaps forward are just formalizations of things good programmers already do, and I think that this qualifies.
If your bitterest enemies are people who hack the heads off civilians, then I would say you're doing something right.
NEW eXtreme Programming Refactored, Take 2 Now with a side dose of Ritalin for those times when even you cannot control your code slinging madness. Take 2 and try again in four to six hours.
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.
"You keep using this word "customer". I don't think it means, what you think it means".
The golden rule applies. You know: "The one with the gold makes the rules".
It's not fair, but if you tell your customer or manager that he has the responsibility because you're using eXtreme Programming, you won't be using it very much longer (assuming you still have a job).
My problems with XP are:
- The XP references to test development skip over a huge can of worms. Where I work (a disk drive company), the product firmware engineers don't write, or even know, the test system languages, and we use more than a few. In addition , many of the tests are canned, or beyond our control, like WinBench. IMHO, test software needs it's own team. It is unreasonable to say the product firmware engineers will just "code up" a test to verify a new feature. The test code could involve as much work as the product feature.
- Working in teams. We have a couple of asian engineers who don't seem to have a firm grasp of, how can I put this delicately, "personal hygiene". I would not like to be the "partner" of either one. We couldn't pair them together because they work in different disciplines. And most of the engineers here are code cowboys who would strongly rebel at having someone peer over their shoulder full time. Personally, I would have to troll slashdot from home, and how much fun is that?
I'm sure I could come up with more, but my pesky manager wants a 1x1 meeting now. Damn.The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
"A few harmless flakes working together can unleash an avalanche of destruction" -www.despair.com
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)
Made ya look. In my experience there is only one programming methodology that works every time:
If you're going to spend energy to make your programming life better, then spend them on the list above.
The meek shall inherit the earth, in 3 by 6 plots. - Lazerus Long
Programmer 1: Dude! We're EXTREME programming! This is so cool!
Programmer 2: OMG my 'chute didn't open! aaaaah!
Programmer 1: We don't need 'chutes! We're frickin' EXTREME! We'll refactor the corpses!
Hats off to you if you've made this methodology work, but to me -- the name says it all.
Back on the day, we did our extreme programming while climbing on a cliff, we used one hand to grab a rope and the other to type on our uber fast 8086... and there were alligators waiting on the bottom... and we liked it.
those were the days
+5 FUNNY.
Because everyone's a friggin' "comedian."
Final Refactoring XII
I have been doing embedded firmware design for the better part of 30 years. From what I've read about XP, I find:
1. everything that XP advocates sounds like the reasons behind every failed project I ever worked on.
2. What XP denigrates and pronounces useless sounds like the reasons behind every successful project I ever worked on.
It makes me mistrust XP right from the beginning.
I am not a big one for rigid design methodology, but I found over the years that the follwoing rules work pretty well:
1. Design from the top down and implement from the bottom up. This just about guarantees that you don't start coding until the design is done and that you have a pretty clear idea where you are headed when you do start coding. A well-documented design effort is not adverse to change; in fact, it makes clear exactly what impact changes will have on the existing work. How in the hell can XP predict what kind of impact a change will have when you don't know what you were going to do in the first place?
2. The most successful projects I ever worked on started by developing the user documentation first! The end-user then had to review and sign off on it before the design started. This caught many, many miscommunications before design ever even started. Instead of being an afterthought tacked onto the end of the project (like most engineering efforts), the user docs provided direction and reference for the duration of the project.
3. The only place to adequately document code is in the code itself. I read once of a company that used APL in a production environment (APL has frequently been described as "write-only" code - no one could read and understand it). They forced each routine to include commnets sufficient to rewrite the entire routine. If a problem was found in a routine and it couldn't be fixed in an hour, the code was stripped and the comments used to rewrite it. This is to be strived for and elminates the need for programmer pairs in XP.
There are many more, I could go on and on (and probably already have). The biggest problem I have with XP is that it tends to throw out everything that isn't "fun" and substitutes any kind of rigor with chaos! Well, damnit, fun is being able to meet deadlines and functional goals, NOT to code constantly, willy-nilly, and never produce a product. And, most certainly, it is NOT 'inexplicable termination' of a horribly late project that has failed in its very reason for existence!
Huh. If you have "a team of creative, engaged, disciplined professionals working together" you will get good results no matter what methodology is alleged to be in use.
Get good people who can work together and let them work, and you'll get good results.
"How to Do Nothing," kids activities, back in print!
It's been replaced by the new methodology: "Offshore Programming" :
(a) None of this "customer user story" crap that has management need to have regular contact with the development staff. Instead you give them the specs and they do the work without talking back to you. Management's time is valuable and can't be wasted on petty programming implementation details.
(b) Wasting time on testing is foolish. You pay people to do the work, so they should do it right the first time. If not there are plenty of others to replace them.
(c) Pair programming doesn't go far enough. If you can put two people in a cube, why not more? And reduce the space, too. But having a person looking over a cube-mate's shoulder is wasteful. Everyone should be busy producing code.
The new methodology also has these advantages:
(d) You don't have to see the developers. Having a group of geeks in your office detracts from the image you want to present to clients: those people can never be part of your social group.
(e) You save money by hiring people that work cheap.
Extreme Programming - so nineties. We're in a new decade now.
The problem is that OOP doesn't work. OOP doesn't reduce complexity, it just moves it, replacing complicated code structure with complicated class heirarchies. Totally useless.
How many successful software companies follow any programming methodology at all? Microsoft doesn't and most successful open source projects don't either.
Why? Because methodologies are never flexible enough to be suitable for all projects and all developers. Is someone like John Carmack going to benefit from pair programming? Is design-as-you-go going to work for something as complex as a CAD application or a new programming language?
I don't know any experience developer that advocates the full adoption of any methodology for all projects - it's a recipe for disaster. There are some good ideas in XP but they don't apply to all situations. Use your common sense and use what's right for the situation.
I'd never hire anyone that used "Uncle Bob" as part of his professional name. What in the world is this guy thinking? That companies want childish behavior?
XP can be a useful method of developing software, but it's no more the be-all and end-all of software design than the Object Oriented stuff that came before it (That everyone hailed as the be-all and end-all of software design.)
If your management is easily distracted by shiny objects and is not capable of making informed decisions based on the strengths and weaknesses of the teams they manage and the unique requirements of the various projects, perhaps you should be worried. Or perhaps your customers should be.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I haven't, but I'm working on an open source hobby project with one other author. We tend to thrash out the high- and low-level design issues by email, sometimes at great length, and then one of us does the actual coding. This seems to work extremely well for us: we both understand all of the project well, and so can do maintenance as needed; we rein in the other's ambition or enthusiasm where needed, but we also prompt each other's imagination too. And the discipline of explaining it all to someone else helps get the design focused and clear.
I've often thought that something like this would be handy at work, too. In most of my programming jobs I've been left largely alone -- there may have been approval for specs and design documents, and brief code reviews after the fact, but the actual creative stuff has almost always been a solo job; and I think this is wrong. Of course, you'd have to get on with the person in question. And -- even more important -- you'd have to have roughly the same vision of where you want to go. But with those assumptions, I'd expect it to work well.
Actual low-level coding is IMO a one-person job (too many cooks, &c), though reviews are always a good idea -- but you shouldn't need to be doing any real design work then, because it should have been done already. And that's where I think pair programming would really help. Maybe it should be renamed 'pair designing'! Anyone else agree?
Ceterum censeo subscriptionem esse delendam.
I remember going through XP programming or Planning XP and finding a beauty... (paraphrased)
... if you need some testing infrastructure, database, web interface etc and have trouble justifing it to the client- just re-word a story so it has to be completed within the current itteration.
...
XP is full of such pragmatic sidesteps that are against the rules, but required to get things done. sometimes the client needs to be told what is required and not the other way around.for this reason developers who strictly adhere to it's rules are forever going to be caught off balance.
My biggest gripe with XP is customers writing stories that define their own problems. It just does not happen with shrink wrap applications. I suspect that this only works with certain types of application development say internal products.
peterrenshaw ~ Another Scrappy Startup
I find that approach really childish and not at all professional. It may take a little time but I'd rather point out the reasons it's silly a few different ways and compare it to other featurews of the system, to make the user reconsider a silly requirement.
I look at it this way - if a requirement is really silly, then it should be easy to talk just about any user out of it. At the end you come out with a much healthier relationship between you and the client.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
While a small team of good people almost always produce good output, I think XP will give much better results than a heavyweight methodology like RUP.
Conversely, a team of average or mediocre people using RUP will probably produce acceptable result, but if the same team uses XP (or another light-weight metodology) the project may very well crash and burn.
For your consideration the following passages:
Paraphrased XP from the book/review:
"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. "
CMMI tutorial:
"Adopter Types:
Innovators
Early Adopters
Early Majority
Late Majority
Laggards"
The Innovators will be the first to embrace CMMI and the Laggards will be the last.
The The Emperor's New Clothes:
"Their colours and patterns, they said, were not only exceptionally beautiful, but the clothes made of their material possessed the wonderful quality of being invisible to any man who was unfit for his office or unpardonably stupid."
Do you see a pattern here?
Apologies to the previous Slashdot poster who originally posted the below text, but I though it was so on the mark that I copied and kept it. It bears repeating:
I've seen SO many of these come and go. You can never question them while they're in the ascendancy.
Stage 1 consists of proof by repeated assertion, and "case studies" that actually describe only how projects using the Methodology were _started_. Lots of detail on how managers and workers were organized and brought on board, etc. Anecdotal success stories where you cannot tell whether the success actually had anything to do with the use of the Methodology or whether they just had a good team that would have succeeded anyway, or whether it was just Hawthorne Effect. No clear evidence that _other things being equal_ using the Methodology instead of some other process actually has a beneficial effect.
Stage 2 occurs when a Methodology has been used in enough real projects by a real-world variety of programmers, then you start to see the articles that say "in order for it to work, you MUST have conditions a, b, c, d, and e." One of the conditions is usually the enthusiastic involvement of upper management. But, hey, if you have the enthusiastic involvement of upper management you can probably get ANY project to succeed. Another is usually the adoption of the entire methodology, no "piecemeal" approaches. Another is usually the provision of adequate training. No real-world project ever meets all these conditions, therefore no failed project using the Methodology is deemed to disprove its efficacy.
Stage 3 occurs when people start to notice that the Methodology doesn't particularly work. Well, actually, it's never phrased that way. Nobody ever _admits_ that the Methodology was a fad which has now been abandoned. Instead, they simply say they are adopting the _new_ Methodology, which it is said, DOES work. Or at any rate WILL work. Provided, of course, that you adopt all of it, have the enthusiastic backing of upper management, and adequate training.
I heard it, I heard it, I heard it on the X ... ZZ Top
Used to listen to Wolfman Jack when I was a kid in Northern California, and only much later found out it was probably his extra powerful station just across the border in Mexico.
Infuriate left and right
20 year programming veteran, from embedded systems, drivers, OS's, up to application and systems management code with everything in between. I'll give an unsolicitied Voice of Experience (as the author calls it) about an unsuccessful attempt at XP:
When XP showed up in our shop it was at a suggestion from the new CTO. Should we do it? Why not? We talked to some consultants about it -- and that's where the wariness set in.
The programmers embraced it for the first year or so. We had good reason to, as it was the only way we could cajole customers (internal personnel) into giving us good problem descriptions. Any methodology was better than no methodology.
The customers complained that the coach was getting in the way of getting problems solved (and he was). The methodology itself was seriously getting in the way of things getting done.
We went from Quarterly development cycles to Bi-weekly. The customers howled in pain, even though the bug count was dropping significantly.
Unit tests never really happened (and yes, the XP-heads will point and scream "THAT'S WHY XP FAILED!" I'm sure). We were working on adding features and bug fixes to a 20-year-old product that strongly resists any attempts at automation or limited unit tests -- caution, experience, and good source control saves our bacon daily.
Pairing... We had 6 programmers, so pairing all-day every day became tiring. So we cut back on the pairing hours. And it was still tiring. And after a couple of rotations, we stumbled on lots of pairings that just didn't work. So with programmers C, W, B, K, P, A the only pairs that worked were CW, CB, CP, WB, WA, BA, and KA. Most of our pairings were expert-expert pairings as far as programming abilities, but in subject matter they ranged from expert to novice.
A lot of knowledge transfer happened during pairing, but a lot of productivity was lost. And the complaints about not being able to tinker and study code to learn from it abounded.
Myself, I thought the whole experience was worth a try. What doesn't kill us can only make us stronger, right? The CTO is gone now and with it most of the methodology.
What we've ditched: * Pair programming, except as a knowledge transfer tool on new code. * The Coach. * Replaced the "stories" with a good bug tracking system.
What we kept: * Somewhat shorter development & release cycles * The dream of good unit tests * 100lbs of books on XP. * Large workstation screens.
Get off my lawn.
Good review! Though I doubt I will read this book (or any of the XP books). All I need to know about XP was answered by Chromatic's little O'Reilly book on the subject (which is a book every programmer should own I think). The pros and cons are pretty clear to an intelligent experienced programmer.
I use a lot of XP's practices, because they literally changed programming for me from a boring, tedious "egg-juggling" problem, with overly complex untouchable code and confused customers ("what is that checkbox for, I didn't ask for that") to a slow and steady but FUN process, with working software at every stage, and nice 8-hour days where I could choose almost any point to stop.
Some reasons why I like XP, or rather, why I've bought into some of what the XP'ers say:
TerminationCanBeSuccess
Yes, it can. I have personal experience with a large, badly-written, sprawling project that I was afraid to touch. The usual thing you've all probably worked with as programmers.
So I took this project and "redesigned" it from the ground up, using diagrams, layered design, the works. Then I began to rewrite the entire thing. After a couple weeks I was nearly drowning in my own code (and my own stink from 10-hour days). It was just way too complex to keep in my head. I began to doubt myself, I used to be able to keep an entire program in my head and visual the design.. was I getting old?
No, my brain now simply had too much stuff in it to keep in short-term memory all at once, and the programs I work on get longer and more complex. I shouldn't limit myself based on the size of my short-term memory.
I had been reading the XP book mentioned above and decided that "you aren't gonna need it" and "test-first development" where really good ideas. I began writing tests and refactoring the existing code, and after about a year the code is now nearly perfect, and with high test coverage (and it was in use the entire time, so I didn't have to maintain two code bases). I am still amazed at how easy it was to write tests, refactor in small steps, etc.. it seemed insurmountable but eventually it was done and that was a great feeling.
In that case termination *was* success.
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'.
The review confuses me here.. if "the customer insists on it", then it's part of the requirements, and you should at least *allow* for the eventual possibility. If this is XP then I'm not using XP properly I guess.
But generally this is good advice. DO NOT CODE AHEAD OF THE REQUIREMENTS. I have examples from nearly *EVERY* project I've worked on where I thought the customer would request a feature, but never did. So like an idiot I have to maintain code that nobody wanted. So even if you think it is "obvious" and you did the exact thing on a project last year, blah blah, DO NOT CODE AHEAD OF THE REQUIREMENTS.
There is an important thing you have to do though. You have to make it clear to the customer that they are an active participant, and they need to give you CONSTANT feedback. I'm working with a customer right now who seems to expect that I will magically "guess" what he wants and he gets upset when the program isn't completely finished like something shrink-wrapped. This is a highly domain-specific app and that's just not possible. He'll get the message eventually, most customers do.. they need to not be afraid of asking for even the smallest little thing. They need to think of us as a voice-driven prog
As the parent pointed out, pure Extreme Programming cannot be offshored. (Unless you also offshore the client)
That's why some people think that XP (and other very customer involving methods) will be the only ones used in North America in the near future, as all projects using more classic methods (with documented requirements) will be offshored.
I guess that some classical projects will remain, but in general I agree with this thinking.
So like it or not, you may be forced to use XP, move to India or change your job.
I have discovered a truly remarkable proof for my post which this sig is too small to contain.
a review by Ron Jeffries with links to other books that talk about the limits of XP
Well, it's not often as profitable to write a book on the downside of a hot trend
I have noticed this also. I could not find much on criticism about OOP when everybody and their dog kept talking about it as if it was the greatest thing since structured programming. So I eventually started my own website on the topic. It is now the most popular OO criticism site on the web (brag brag). I wish there was money in it so that I could spend the time to reorganize it, clean it up, hire proof-readers, etc. But it is what it is.
My point is that one is more likely to find criticism of a new technology or technique on the web rather than in books.
Table-ized A.I.
The one thing people seem to miss, imo, is that methodologies like XP require a high degree of discipline/maturity in the team.
A panel I went to on methodologies (OOPSL '00) mentioned this... that light methodologies work well with people who have a good degree of experience and good discipline. In teams like this heavy methodologies (e.g. look at PMI sometime, or RUP) tend to bog the team down. This sort of team tends to have a good degree of knowledge of the domain, and tend to be experts in the tools they use.
On the flip side... a relativly young and/or non-diciplined team can benefit from a heave methodology because it will force them to look at a variety of variables. They might not have good knowledge of the problem domain or a full understanding of the tools avaialable to them. In that case the heavier planning can help them.
I've been in both situations over the years... In the begining I liked the heavier methodologies, more for project managment, because things had to be documented. Now I know more, and do a lot of this automtically. So I've become a convert to things like Scrum which allow me to track empirical evidence, but don't get in the way of my job.
just another $.02
Are you required to have someone sitting next to you watching everything you do?
Are you prohibited from scratching your ass, picking your nose, or phoning your spouse as pair programmers are?
Pair programming is a dead-end.No seasoned coder is going to put up with someone hanging on their shoulder - at best this technique brings together two weak programmers who may at best catch the odd bug when they aren't shooting the breeze.
Nothing beats experience. Pair programming at best is simply a tool to use peer pressure to keep people from cruising porn at work.
I hate XP because it tries to eliminate the part of systems design that I consider most important...
"When the going gets weird, the weird turn pro" -- HST
My new company has adopted XP ways before I came on board. For the past 3 weeks I have been working in pairs with other programmers, I do not have my own station, we constantly exchange pairs. There is no high level architecture, there are design sessions. There is Swiki to keep whatever documentation we produce as we work on tasks. There is XPlanner to keep track of our time spent on tasks. XPlanner is also used as an integration token (when you want to integrate, you grab a token in it and only then you are allowed to check stuff into CVS.) Before you check into CVS all your code must have JUnit tests written (for every method) and the code must not only compile but also pass all the JUnit tests.
Do I like XP? No, I don't. I think there is a major problem with not having a strong architectural design upfront (especially in our app., which is a back-end J2SE only data parsing - loading - networking system, with strict SLA time lines.) Pair programming? - I don't really care, if the company is paying for it, it is not my business. Of-course I hate the fact that I don't have my own station. JUnit testing everything, every method? I think that it is a great idea if you have the time. I find that it helps flushing out the bugs early on. Of-course it is the most time consuming portion of the coding exercise, especially if you have to mock all the database stuff before running your DAO tests. SWiki is a good idea, I think, but it is not a substitute for a high level design document. It is descriptive of the tasks but it lucks the perspective.
Design sessions with all coders at once? A horible idea, but how are you going to share info when there is no documentation? Basically in XP you either do all of these things or your project will really go to hell. I don't like it. If all developers were to leave at once, another group could not find enough documentation on the business requirements of the project to continue working. XP blows in my mind, but it is a job for now.
You can't handle the truth.
I paired programmed on two projects in a row. One project a resounding success (you can see it yourself running in the stores of a major US retailer). One project yet to be determined, but probably a resounding failure. Like all the detractors would predict me to say, the probable failure had little to do with Paired Programming.
/., checking your email, etc. when you have a pair.
I miss pair programming. I think we got way more done, way faster, than on projects where I've single programmed. Partly because in pair programming there was way less time spent fixing somebody else's code since it tended to be done right the first time. Partly because there was way less time chasing after someone just to figure out how some piece of code was supposed to work - because there was a high probability your pair had worked on it or seen it. Partly because, yeah, you're way less likely to sit around picking your nose, checking
I also think all the programmers on the team got up to speed on the technologies, architecture and practises way faster. I'm now on a non-pairing team. The other folks have been coding together on various projects for a couple years - but always on their own code. A couple of them are taking for ever to get going on good practices or even technologies - cause the only way they get the knowledge is through ordained "knowledge transfer" sessions. Yeah, I get as much knowledge out of those as when playing Warcraft.
I also think we had supremely effective code review in pair programming. Do we have code review now? Yeah, once every quarter we get together because it is required to fill out some code review paperwork. We look at a class or two. We comment on some variable names and indentation. Nothing gets changed of course, because the code has already been system tested and deployed to production by that time. So we get about 2 percent code review, which results in zero percent code quality improvement.
Now, in my current team, maintenance tasks and new feature tasks queue up behind the programmer familiar with that code. Oh, he's out sick or on vacation? Or just working on something else? Then you'll have to wait. Meanwhile, someone over here is working on some low priority task - they could do the work, but they'd probably mess it up or just take forever to figure it out and try to tread lightly through it, since it will look completely different from everybody else's and their own code. Meanwhile, they start re-inventing some stupid little wheel like an email validator or a phone number validator (please accept these for the examples they are and don't go off on a harangue about them) because they don't know if someone else has done one yet. So then you end up with five or six different implementations of the same darn thing. Some stupid little thing, the kind of thing that isn't dictated by your architecture and brought up in your team meetings. The kind of thing you don't blab about over your cube wall. Little consistencies in the code that would make future development that much smoother and faster don't get into place. Little consistencies that DO get implemented when you pair program all the time.
That said, on the successful project I mentioned above, we reduced pair programming near the end. We still worked together in a lab, without cube walls, which helped maintain communication like, "Hey, I need an email validator. Have we got one?" But since everybody was experienced on the project and everybody was knowledgeable about the architecture, the technologies and the practises, and the indentation fetishes, 100% pair programming wasn't necessary.
Furthermore, coming off the (as yet to be determined) failed project - it was a [expletive] relief to get out of paired programming, since that project had been a constant death march, which is way more depleting when you are pairing all the time. It was (is) a nice luxury to sit in my high walled cube and code away all day. But I miss the learning curve, the sense of confidence that I understand the code from end to end instead of my own little cogs. I miss having to break from the flow of development to go find another developer to bounce ideas off of.
...I think it's worth pointing out that one of the authors, Doug Rosenberg, has his own consulting company which supports his own software development methodology. <shrug>
Downmodding is the refuge of the weak. Don't downmod, make a better argument!
We did *that* in my first CS term. As I remember it went a little something like this: one guy does all the work while the other sits back and jerks off.
Because Geeks can't snowboard.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
Attempts to do this with PCs have been less successful, because synchronizing the displays tends to require huge bandwidth.
We just finished a two-month experiment with Extreme Programming on my team of six. We really made a strong effort to do it right, because we saw an advantage in going the whole nine yards, and because we also saw the instability of a partial implementation. We spent a couple of weeks up front reading the books (pro and con), debating the issues, and coming up with a plan, then we did four 2-week iterations. The result was an unqualified success. Productivity shot way up, morale improved, and we are much happier with the quality of the code. Now we are laying down plans to continue this way indefinitely. We had a few skeptics at the start of the process, especially on the topic of pair programming, but now they are strong advocates. Upper management is very happy and wants to expand the practice.
If you are interested in XP, you must understand that it takes a lot of discipline to do it right. You will need a lot of up front time to talk about and change your habits, and some patience while you work through a new process. If you have people on your team who don't like to roll up their sleeves, or who aren't competent, XP will not fix them. If your senior people have no desire to slow down enough to mentor less experienced members of the team, XP won't work there either. The process requires a certain amount of intelligence, cooperation, and altruism. If your team is lacking in any of those areas, be prepared for failure. If your team has those qualities, hang on and enjoy the ride!
This is the third time that I've been in an XP implementation, and each time has been a fantastic experience. It's nice that XP really works, but the best part of all is that it is just plain fun.
I just wanted to thank the author of the review for one of the first good reviews I have read on Slashdot. Too often reviewers are basically just listing the table of contents and adding "and I liked it" at the end.
Here for once we have someone who goes a bit more in depth and tries to evaluate impartially the things the book discuss. Amazing!
Being bitter is drinking poison and hoping someone else will die
I stopped reading the review after the author described UML as a software design methodology. I'll have another go at reading it in a bit, but I've got a feeling I'm not going to agree with it.
I'd have to disagree. I'm not saying that the review wasn't well written, it's just it's misleading to call it a book review. It's a summary of the book, and exposition of its main arguments. The reviewer agrees with the book's main thesis and has helpfully summarized it for us. The reviewer has told us very little about how good a book the book is (which is what a book review should do).
Posters recognized by their sig,
...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?
I think that all good and idealistic ideas must be viewed from the same point as the idealistic and perfectionalistic martial arts of the East. The best example coming to my mind is Aikido.
While an experienced teacher can explain the movement of your fists like "the fall of a dry leaf stopped by a mountain spring" and you must understand it before you can do the move correctly, an inexperinced teacher will try to explain the principles in phisical, concrete examples, direct words - and these words will not be a precise description of the move making you fail to accomplish it without you acctually understanding why.
I think that XP is an art of programming, that just had no good teacher to explain the fundamentals of the process precisely enough.
When you learn Aikido, you go trough three phases:
1. You learn what Aikido is and try to repeat it
2. You find new moves that organically follow from the ones in Aikido
3. Every move you do is Aikido whenever you want it or not.
Only masters that have reached the third level can understand the principles of the art, but only those in the second level can teach it.
What I see in XP is the lack of a house of 3rd level masters surrounded by 2nd level masters that could pick up and distribute their knowledge in a form pure enough for people to see the art behind XP and simple nough for them to understand.
Scrum - http://www.controlchaos.com/
Take the good bits out of XP
* Rapid Development
* Fast releases
* Customer input
* Clear workload for developers
And removes some of the bad
* Obsession with daily releases
* Little chance for developers to put own issues or structure into product
* Pair programming
XP, UML, Patterns and all the other cultish methodolgies cannot hope to usurp Fred Brooks' fundamental law:
"There ain't no such thing as a silver bullet".
BubbaJon
"That brings the unique capability of the Internet to connect people with shared interests, together with the ability to perform some kind of action in the face-to-face world."
Like the German cannibal who met and ate a willing victim he found on the net?
Absolutely agreed. That's the point I was making.
The lower your expectations of your people, the more you fear bad results, the more process you put in place.
Don't but bad drivers in Formula-1 cars.
Conversely, if you have a high caliber team, the you can get by with less process, instead focusing on aligning their programming disciplines.
Don't put champion racers in a Ford Festiva.
Now, when you really get into trouble is when you try to take the same disciplines that let talented professionals at the right-hand tail of the bell curve go really fast and apply them to the center (or left-hand) of the bell curve.
"Genius may have its limitations, but stupidity is not thus handicapped." --Elbert Hubbard (1856-1915)
sceptre1067, you must be brilliant because I agree 100% with what you just said!
"Genius may have its limitations, but stupidity is not thus handicapped." --Elbert Hubbard (1856-1915)
As my teacher used to say...
Thats RONG wrong. I was strongly under the same opinion as you until I got OOP working for me. I was always of the opinion that it was a lot of extra work that didnt really pan out into useful stuff. This on top of the obvious performance hit, made me think that OO design was just stupid. After writing a few signifigant projects in it, Ill never go back. (I know Im proselytizing but I do love it.) It really speeds development in the long run simply because of the gains in maintainace of everything. If I know that no matter where I want to hit the Contacts table in a huge database app, it all goes through the objects.Contact class, its a beautiful thing. The best part is that I know everytime any of the other 5 programmers on the project want to hit the contacts table. All their interaction is also in the same class. Meaning I can change the whole programs interaction with contacts in a single place.
I have my doubts about merits of Pair Programming as described in the freely available chapter of the reviewed book.
However, I would strongly advocate 'Pair Debugging', once the code builds and passes unit tests but does not work when integrated into the system.
First, there is an issue of tools, say, debugging an FPGA on a board in a system. Quite few people can individually operate and effectively evaluate results of source code debuggers, Verilog simulators, ICE, logic state analyzers and scopes. So, this necessitates the obvious and often unavoidable pairing of a software and hardware engineer.
More frequently, though, for any system that's large and old enough, one person can hardly span interaction of various components under diverse inputs, and having two or more people observing and analyzing steps leading to a failure is very productive.
So, in conclusion, I think using 'Pair' methods is justified if knowledge and skills of the two engineers are complimentary.
Yep, with all these buzzwords like: Synergy, proactive, paradigm.
Obligatory Simpsons Quote:
"The Itchy & Scratchy & Poochie Show"
Myers: I have figured out how to rejuvenate the show. It's so simple,
you egghead writers would've never thought of it! What we need
is... a new character! One that today's kids can relate to!
[writers look at each other, uncertain]
Oakley: Are you absolutely sure that's wise, sir? I mean, I don't want
to sound pretentious here, but Itchy and Scratchy comprise a
dramaturgical dyad.
Krusty: Hey, this ain't art -- it's business!
-- That's the spirit!, "The Itchy & Scratchy & Poochie Show"
Krusty: Whaddya got in mind? Sexy broad? Gangster octopus?
Myers: No, no. The animal chain of command goes mouse, cat, dog.
[to the writers] D-O-G.
Weinstein: Uh, a dog? Isn't that a tad predictable?
Lady: In your dreams. We're talking the original dog from hell.
Oakley: You mean Cerberus?
-- Does he drive a `Persephone'? "The Itchy & Scratchy & Poochie Show"
Lady: We at the network want a dog with attitude. He's edgy, he's "in
your face." You've heard the expression "let's get busy"?
Well, this is a dog who gets "biz-zay!" Consistently and
thoroughly.
Krusty: So he's proactive, huh?
Lady: Oh, God, yes. We're talking about a totally outrageous
paradigm.
Meyer: Excuse me, but "proactive" and "paradigm"? Aren't these just
buzzwords that dumb people use to sound important?
[backpedaling] Not that I'm accusing you of anything like that.
[pause] I'm fired, aren't I?
Myers: Oh, yes.
-- Is that what happened to Jon Vitti?,
"The Itchy & Scratchy & Poochie Show"
Meyer: The rest of you start writers thinking up a name for this funky
dog; I dunno, something along the line of say... Poochie, only
more proactive.
Krusty: Yeah!
[Myers, Krusty and the lady leave]
Oakley: So, Poochie okay with everybody?
All: [reclining in their chairs] Yeah...
Sorry if that sounded too harsh, but maybe because of things like this XP is regarded by some as a religion and not a viable design method
jethroT, I understand what you mean. It does sound that way when phrased so baldly. It's almost a politician's statement -- unarguable, because no one would ever attempt to justify doing things that have no value.
It can actually be useful, though. Consider a typical large corporation. They tend to be bloated, slow, and rigid. Why? Because people do a lot of things that are unrelated to their project.
At a corporation I consulted for, in one week, I saw a Red Cross blood drive, a foodshare program, a concert for the employees, and an "all-hands" meeting that discussed a change in management 4 layers above all the people in the room. These took an average of 6 hours from each of the team members. None of that was delivering value to the customer, but not one of the developers on the team felt they could say "No, that doesn't advance my project". (You can definitely make a case for delivering value to other stakeholders: employees, shareholders, the community, etc. XP doesn't say that these are inherently bad, it just says they don't get the project done.)
In a more directly connected vein (pun intended), most development project are encumbered by various enterprise initiatives that don't help the project: archaic coding standards, enterprise version control groups, enterprise data architecture groups, etc. Each of these crosscutting functions is, in theory, present to create an efficient enterprise through skills focus and specialization. But, when you combine a heavily matrixed organization with an extreme focus on efficiency, the result is ever-increasing lead times to get on that groups calendar.
Does an enterprise data architecture group accelerate projects? It certainly can. Does it accelerate projects if you have to wait 3 weeks to get a schema reviewed, followed by 2 weeks to get the schema created? I think not.
The wait time delivers no value to the customer. XP says to eliminate it by using a tightly integrated team, instead of a matrixed structure. That's one (windy) example.
I would say that you could construct almost any development discipline from that premise--except that most of the ones out there weren't built that way. Further, I would say that if you constructed a development discipline around that premise, it would look a lot like one of the agile methods. Not necessarily XP, but XP's not the only agile method around any more, either.
"Genius may have its limitations, but stupidity is not thus handicapped." --Elbert Hubbard (1856-1915)
To put that as an achievement of XP is like saying Windows invented the GUI.
Incidentally some of the methods of XP violate the principle (TDD for example, does a test case benefit the customer?) first to have an end result that does benefit the customer. But thats true for every other design methodology in existence.
In the end every design method wants to benefit the customer. That a corporation has a big bureaucracy that works contrary to these goals is just the effect of reality on a theory.
You are completely right with your critique of the schema reviews and bloated structures, but when these design principles where thought out, I'm sure everyone thought it would ultimately benefit the customer. One could argue that the principle behind XP is 'Smallest possible organisation' or something similar (don't pin me on that, I don't have the time to think of something better), but 'Do only what benefits the customer' is a catch-all for any good design principle.
A second reading shows that I might have been too hasty in turning off -- the long summary of the book might have been a simple paraphrase, reflecting only the authors' opinions and not those of the reviewer. By the end of the second reading, I'm still not sure which way to read it, so I'll give benefit of the doubt.
My second reading also revealed several other wilful misreadings and misrepresentations that the authors had published in earlier material, and had been called on. For instance, that "XP is risky": each of the practices in fact manages, in part or whole, at least one risk which prevents software teams from delivering software. Or that "XP is good only for maintaining software": in a sense that's true, but only because the first releasable build happens immediately and it's all maintainance upgrade from there!
Overall, I hope that the reviewer will have an opportunity to examine "Extreme Programming" further sometime later in his career. At the very least, that the negative spin by the authors on XP will not keep him from looking at other "agile" methods and practices which can benefit his team and his organization.
---- Joseph Beckenbach lead XP tester, Eidogen Inc.
traditional? what's that?
A guy who works alone
(i drink alone too).
I've used XP (pieces, not the full ball of wax) in two very big, important projects and we've been successful. We didn't use all of XP because the managers, project sponsors, and some of the techs weren't comfortable moving to full-on XP. Both systems are in production.
I haven't read the book and have no interest in reading the book. I think the book's authors and the reviewer are likely nice guys however I was put off by the 'attack mode' which rings of (1) character assassination and (2) someone else's methodology (Not Invented Here).
Yes, in the real world of programming projects some head tech/manager dude usually is laying down the law about methodologies, technological direction, design techniques, etc. Yes, I'd trust the luminary/author who came up with those pop-Zen sayings to design and implement a 10000 tps system, shocking as that might seem after this review. Yes, getting buy-in from management to do anything in a project is extremely important.
"Foisting" XP or anything else on unwilling or incredulous managers/workers won't succeed. That seems reasonable enough. Assuming it's all bad because some goof tells you so seems kind of overboard as well.