Extreme Programming Refactored, Take 2 277
| Extreme Programming Refactored: The Case Against XP | |
| author | Matt Stephens and Doug Rosenberg |
| pages | 432 |
| publisher | APress |
| rating | 8 of 10 |
| reviewer | Sarusa |
| ISBN | 1590590961 |
| summary | A book you should definitely read along with 'Extreme Programming Explained'. Makes its points quite well, though a bit over the top in places. |
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 Points
If 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:
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."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."
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.
Could someone refactor the review? (Score:5, Funny)
Cue lame "Windows XP" jokes (Score:2)
definition: (Score:2, Funny)
fecundity-The quality or power of producing abundantly; fruitfulness or fertility.
buzzword phenomena (Score:5, Insightful)
Re:buzzword phenomena (Score:3, Insightful)
Yeah, lazy (which isn't always a bad thing, some kinds of laziness are good for efficiency) programmers who fly by the seat of their pants trying not to get too close to the sun (ok, a couple cliches and puns there...) have always existed, but now they get to call themselves XtremeProgramming specialists on their resume.
The resume they'll need badly once they manage to almost fully implement XP...
Re:buzzword phenomena (Score:2)
Re:buzzword phenomena (Score:2)
Dang (Score:5, Funny)
-A
Re:Dang (Score:5, Funny)
Who needs to buy the book, i read the whole thing in the article :)
No, I think the article is a little longer.
eXtreme! (Score:3, Funny)
My experience with XP (Score:5, Funny)
Re:My experience with XP (Score:5, Funny)
Re:My experience with XP (Score:2, Funny)
Re:My experience with XP (Score:4, Funny)
wait, what? (Score:5, Interesting)
So you're telling me that the basis of extreme programming is a failed and cancelled project? live and learn i guess.
Re:wait, what? (Score:3, Insightful)
Re:wait, what? (Score:4, Funny)
NO silver bullet! (Score:5, Informative)
Re:NO silver bullet! (Score:2)
Re:NO silver bullet! (Score:2)
What are you talking about? I love writing documentation. It's like an outline or rough draft. I write out how I want my code to work and what it's supposed to do, which usually really helps me clarify in my own mind what I need to work on. Analytical writing skills also translate quite well to code analysis, so if you think about your project from that perspective you'll usually find s
XP, Windows XP (Score:3, Funny)
Having said that, Windows has come a long way from the 9x series.
Customer responsibility (Score:5, Interesting)
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
Re:Customer responsibility (Score:5, Insightful)
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.
Re:Customer responsibility (Score:2)
Wheee
Re:Customer responsibility (Score:4, Insightful)
As indigo montoya might say (Score:2)
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).
Re:Customer responsibility (Score:5, Interesting)
I've found myself on the developer side of this on numerous projects. The other side was either the QA people or actual customers. What I've done that works pretty well is: I code up tests for everything I can think of. I stick them in a directory called "test", and run everything there (in alphabetical order
When the QA or customer rep makes the usual complaints about how complex and poorly defined their job is, I introduce them to my test suite. They are usually overjoyed that I've done their job for them. Then I tell them that I don't think I've done their job. My test suite is almost certainly incomplete. I give them a list of the things that I have tests for, and tell them to go off and think about it. I expect them to make suggestions for new tests.
Their suggestions are sometimes good. Other times they are vague and unprogrammable. So I try to get them to clarify. And so on. It's somewhat random, but usually a lot of useful ideas come out of it.
Eventually they have not just a "product", but a set of validation tests that show what it can do. And the contents of the test directory constitute a HOWTO for their own programmers stuck with the task of using the stuff.
The one major problem with this is that it's difficult to program tests for features that require user interaction. Simulating a human is not easy. If that human is hidden behind a WIMP interface, it's nearly impossible, no matter what people will tell you when they don't have to do it themselves.
most tired buzzword ever... (Score:3, Funny)
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."
Stupid X acronyms.. (Score:4, Funny)
Re:Stupid X acronyms.. (Score:2, Interesting)
A radio station in Quebec city, named "Radio X", popular mostly to people aged 16-25, even invented a new concept named "the X attitude". They always ask people "have you got the X attitude ?" and the worst is everyone answers the french equilalent of something l
Re:Stupid X acronyms.. (Score:2, Funny)
Re:Stupid X acronyms.. (Score:2)
my personal take.......... (Score:2, Funny)
yeah, yeah, check my spelling!
Re:my personal take.......... (Score:5, Insightful)
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.
Re:my personal take.......... (Score:5, Insightful)
Re:my personal take.......... (Score:2)
The question of how easy or difficult it is to get people to follow the rules of a methodology is a legimate measure of that methodology's effectiveness.
Pair programming itself is based on the idea that an individual programmer can be a bit lazy and thus not double-check their work. Well, when you pair to lazy people together there's no guarentee that they will
Re:my personal take.......... (Score:2)
Bzzzzt. "the two of us"???? Yes you program in pairs, but under XP, you're also supposed to exercise collective ownership. That means rotating frequently, so everyone pairs with everyone else. Ideas in the code spread that way.
Now, if there were only two of you on the project, and both of you couldn't be bothered programming, then no methodology's going to fix that.
It *has* been said that two cowboys sitting next to each other will still be more produ
Why not "EP" instead of "XP"? (Score:5, Interesting)
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!"
Re:Why not "EP" instead of "XP"? (Score:2)
That said, I hate when they Capitaloze the wrong letter and then use it for an intial.
It is so stooopid.
Re:Why not "EP" instead of "XP"? (Score:2)
What will the 2nd edition be titled? (Score:4, Funny)
3rd Edition: "Extreme Programming Refactored Refactored Extremely Refactored"?
Re:What will the 2nd edition be titled? (Score:2)
I think the third one will be:
- Extreme Programming Revolutions
As in when the programmers revolt and stage a cyber-coup.Seriously, I did some test-led development, and that really helped out in defining issues early on... not sure if pair-programming or use-stories would work (we extensively use UML use cases at the requirements stage).
Coming soon... (Score:2)
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*
XP (Score:5, Interesting)
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.
Re:XP (Score:5, Funny)
>He no longer works here.
No, he just got so good at it he doesn't have to work more than 0 hours per day.
Proof by example.
Re:XP (Score:3, Insightful)
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 fo
Re:XP (Score:2)
General Principle (Score:3, Insightful)
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.
Was that the whole book? And.. (Score:2)
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.
Reasons for XP (Score:5, Insightful)
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.
Re:Reasons for XP (Score:5, Insightful)
Sure I write way better code, but it also takes me a lot longer.
my experience disagrees. In my earlier career, I'd often blast out something that showed good signs of progress but had to have major redesign/recoding before the product could fulfill the requirements. I think my overall productivity is now much improved through forethought and consideration of design (though obviously some of the improvements come from the brute force of experience).
I think XP is partially inspired by a desire to recapture that youthful productivity
You may have something there. My disipline is the result of years at the 'school of hard knocks' and when you're busy getting 'hard knocks' you're not being used as efficiently right now as you could be. Some students never graduate from that school, so I think all coders can benefit from a structured methodology, the lesser experienced most of all. I just feel uncomfortable with what I see as an overzealous streak in this burdensome system (XP).
Re:Reasons for XP (Score:3, Insightful)
I think it's rather that overdesigning and overgeneralizing (or in XP terms, writing code you don't need) is a waste of developer time and customer money better spent solving the customer's most important problem. Increasing programmer joy of programming is a nice side benefit.
Re:Reasons for XP (Score:2)
Re:Reasons for XP (Score:3, Insightful)
Part of this was the observation that if you could walk through a company's software development areas, you could quickly g
Re:Reasons for XP (Score:3, Interesting)
I'm only 20 years old, but I'm a very fast learner, and I am very conscientious about the quality of my code. Moreover, since I work on a very small team, I end up contributing to every single step in the process, from db/schema design to semi-advanced SQL coding (nested sets for hierarchies instead of recursion-based methods, for example) to object model planning and data/business/presentation separation planning -- and, of course, every phase of the actual pr
Why it's not taking off... (Score:2)
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.
Re:Why it's not taking off... (Score:2)
There is no silver bullet.. (Score:3, Funny)
XP Refactored (Score:5, Insightful)
Re:XP Refactored (Score:2)
Ummm... yeah... but only because the terms "schedule", "late", "success", "bug" and "software faults" have been redefined so substantially. When the results are held to the same standards (i.e. on the originally-desired schedule,
Re:XP Refactored (Score:3, Funny)
When I see someone slinging around unattributed percentages like that, the credability drops to 7.5% and my attention span drops to 0%.
Windows XP (Score:2)
I thought that was a decent review: definitely more informative that most of the book reviews they have here on Slashdot.
Excellent Review (Score:5, Insightful)
Other people submitting book reviews should read this one first. Thanks Sarusa!
Funny.. (Score:2, Interesting)
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.
One incredibly useful part of XP... (Score:3, Interesting)
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.
Re:One incredibly useful part of XP... (Score:3, Insightful)
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 formal
NEW eXtreme Programming Refactored, Take 2 (Score:2)
Dropping customer requirements (Score:4, Insightful)
Silently dropping these in the trash is often the best way to test if the customer really wants them.
Childish (Score:2)
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.
My issues with XP (Score:2)
My problems with XP are:
As always, mainstream exposure causes corruption. (Score:5, Insightful)
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.
Re:As always, mainstream exposure causes corruptio (Score:2)
Get good people who can work together and let them work, and you'll get good results.
Re:As always, mainstream exposure causes corruptio (Score:2)
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.
Extreme Programming - last decade's fad. (Score:2)
(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
Pair programming (Score:2)
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'
more XP favourites (Score:2)
I remember going through XP programming or Planning XP and finding a beauty... (paraphrased)
Like CMM and Emperor's New Clothes (Score:2)
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
XP at my new job (Score:3, Informative)
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.
Early pair programming. Remote, no less (Score:3, Informative)
Attempts to do this with PCs have been less successful, because synchronizing the displays tends to require huge bandwidth.
Parent is plagiarised. Mod down. (Score:5, Informative)
Re:Parent is plagiarised. Mod down. (Score:2)
Re:I have this book... (Score:2)
What is it that is keeping programmers from reaching a consensus on this. Was Object Oriented design as controversial as XP is?
I'm Cynical... (Score:5, Insightful)
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.
Re:I'm Cynical... (Score:2)
Some who argue against XP say that the above is true for any methodology.
That's My Point (Score:4, Interesting)
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.
Re:I have this book... (Score:2)
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
Re:I have this book... (Score:2, Insightful)
I would like to see a study. (Score:5, Interesting)
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.
Re:I would like to see a study. (Score:2)
Re:I would like to see a study. (Score:2)
To be statistically significant you'd need to do this several times over with several pairs of programmers. Your programmers would have to be a representative sample of programmers in your hypothesis, and the problem (or better several problems) would have to be representative of real life problems.
Slashdot is proof that a reasonable opinion can be instantly improved upon!
Re:I would like to see a study. (Score:2)
I'm a bit disappointed by much of the pessimism in this area. It seems as if people have been infected by the "No Silver Bullet" meme such that they think incremental improvements in methodology are worthless.
Re:I would like to see a study. (Score:2)
Re:I would like to see a study. (Score:2)
Re:XP in a nutshell (Score:2)
I'm SHOCKED!!!!
Re:XP in a nutshell (Score:5, Funny)
int int mamainin (voidvoid) {{
pprintrintff(("%.3ff", "3"vavall;);
retreturn 0;urn 0;
}}
Re:Rational Unified Process (Score:3, Informative)
Yes, finally we have a process, where the training program has been officially accredited and takes 2.5 years to complete. The resulting Ph.D. is very highly valued in industry, and many people exiting the program get hired on in the best bureaucracies around! The best part is that no programming is necessary at all!
Re:Rational Unified Process (Score:4, Informative)
Martin wrote about XP vs RUP in 1998 (gg PDF-as-HTML). [google.com] Martin calls/~ed it "dX" ("dX: A minimal RUP process"). Gary Pollice [wpi.edu], former Rational 'Evangelist', have also explored RUP and XP common ground (gg PDF-as-HTML) [google.com]. Google for more.
"Uncle Bob"? (Score:2)
Re:Just like socialism? (Score:2)
Re:Can someone just explain this in plain talk? (Score:2)
You have to envision the management team as a group of pointy haired men who are being pushed forward and backward by their desires and fears. The hype of XP triggers the desire instinct. Cynicism triggers fear. You need to trigger desire or fear depending on your objective. If you do it right, money falls out of the company's pocket.
As for success of IT projects goes, I realized that the