Extreme Programming Refactored - The Case Against XP
-
This book[^] is a gem. A definite must read, even if you love XP. An exerpt from one of the reviews, which I thing is dead on: XP Refactored is the first book to seriously and deeply critique extreme programming. The authors poke fun at the excesses of extreme programming, of which, by the definition of "extreme," there are many. The book contains the best critique of the legendary Chrysler C3 project I've seen, including a good discussion about why it really is more myth than legend. The authors do a good job of countering Beck's claim that "turning the dial up to 10" is a good idea. Although it isn't the most enjoyable part of the book, the most technically interesting part of the book is the chapter on "Extreme Programming Refactored." The authors see a lot of value in the specific practices of XP; they'd just like to turn the dial down from 10 on some of the practices, reorganize others, and tone down some of the religion. Marc
Marc Clifton wrote:
An exerpt from one of the reviews, which I thing is dead on:
From Steve McConnell, no less. Author of Code Complete[^].
-
Marc Clifton wrote:
An exerpt from one of the reviews, which I thing is dead on:
From Steve McConnell, no less. Author of Code Complete[^].
Leslie Sanford wrote:
From Steve McConnell
That tells me that I need to read the book.
-
In my own experience, there is an exponential relationship between how strongly an individual advocates XP, Agile, Design patterns, etc. and how bad they are as developers and/or managers. (Again, this is my experience, but it has been the single strongest predictor of how bad someone will suck in actual practice that I've encountered.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
In my own experience, there is an exponential relationship between how strongly an individual advocates XP, Agile, Design patterns, etc. and how bad they are as developers and/or managers.
I think they mention that correlation in the book too. :~ Marc
-
This book[^] is a gem. A definite must read, even if you love XP. An exerpt from one of the reviews, which I thing is dead on: XP Refactored is the first book to seriously and deeply critique extreme programming. The authors poke fun at the excesses of extreme programming, of which, by the definition of "extreme," there are many. The book contains the best critique of the legendary Chrysler C3 project I've seen, including a good discussion about why it really is more myth than legend. The authors do a good job of countering Beck's claim that "turning the dial up to 10" is a good idea. Although it isn't the most enjoyable part of the book, the most technically interesting part of the book is the chapter on "Extreme Programming Refactored." The authors see a lot of value in the specific practices of XP; they'd just like to turn the dial down from 10 on some of the practices, reorganize others, and tone down some of the religion. Marc
I must admit I'm not enamoured at all with XP and wasn't when I first read about it and lo and behold the second reviewer on that amazon page Craig Kenneth Bryant summed it up perfectly: "Barry Boehm once published a landmark paper on software defects, relating when you find them to how much they cost to fix. He found that defects were cheaper to fix the earlier in the development process you found them, which should surprise no one-adding or removing a sentence in a requirements document beats the heck out of screwing up everyone's paychecks in a production system. But the interesting part was how much cheaper it was to change a program in analysis than in production-orders of magnitude cheaper. Boehm's data produced a very steep cost curve as the project moved from design to implementation and out to the field-the most expensive place of all. So, years later, along comes a methodology called XP and claims to flatten the Boehm curve. The cost of change is now constant across the whole lifecycle, say the XP evangelists. It doesn't matter if we miss requirements up-front, or if we have to redesign the code over and over. Heck, it doesn't matter if you change your mind about the very nature of the system halfway through development. We're agile. Change is free. And how does XP work this miracle? XP's big idea is to scrap the analysis and design phases altogether, and get the code into maintenance as fast as humanly possible. In other words, XP flattens the Boehm curve by throwing out the cheapest segments of the curve, and spending the entire project in the most expensive segment. "
"110%" - it's the new 70%
-
I must admit I'm not enamoured at all with XP and wasn't when I first read about it and lo and behold the second reviewer on that amazon page Craig Kenneth Bryant summed it up perfectly: "Barry Boehm once published a landmark paper on software defects, relating when you find them to how much they cost to fix. He found that defects were cheaper to fix the earlier in the development process you found them, which should surprise no one-adding or removing a sentence in a requirements document beats the heck out of screwing up everyone's paychecks in a production system. But the interesting part was how much cheaper it was to change a program in analysis than in production-orders of magnitude cheaper. Boehm's data produced a very steep cost curve as the project moved from design to implementation and out to the field-the most expensive place of all. So, years later, along comes a methodology called XP and claims to flatten the Boehm curve. The cost of change is now constant across the whole lifecycle, say the XP evangelists. It doesn't matter if we miss requirements up-front, or if we have to redesign the code over and over. Heck, it doesn't matter if you change your mind about the very nature of the system halfway through development. We're agile. Change is free. And how does XP work this miracle? XP's big idea is to scrap the analysis and design phases altogether, and get the code into maintenance as fast as humanly possible. In other words, XP flattens the Boehm curve by throwing out the cheapest segments of the curve, and spending the entire project in the most expensive segment. "
"110%" - it's the new 70%
XP flattens the Boehm curve by throwing out the cheapest segments of the curve, and spending the entire project in the most expensive segment. Isn't it ironic how something can sound great, but the truth of the matter is there right in front of one's nose, but it isn't noticed because of all the other hype. Marc
-
In my own experience, there is an exponential relationship between how strongly an individual advocates XP, Agile, Design patterns, etc. and how bad they are as developers and/or managers. (Again, this is my experience, but it has been the single strongest predictor of how bad someone will suck in actual practice that I've encountered.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
That may be true, but is the inverse also true? That is, are those who mildly advocate XP, Agile, etc, better developers/managers? I think there are good ideas in XP, mostly around iterative development, i.e., design a little, code a little, find something you missed, refactor, redesign, code, loop until done. But the base process that has always been with us is essential: gathering and understanding requirements, and the desired results. It is also essential to understand how to get there. Without that firm basis, any "process", XP or otherwise will fail. In my experience XP doesn't help there and sometimes even hinders.
Silence is the voice of complicity. Strange women lying in ponds distributing swords is no basis for a system of government. -- monty python Might I suggest that the universe was always the size of the cosmos. It is just that at one point the cosmos was the size of a marble. -- Colin Angus Mackay
-
I must admit I'm not enamoured at all with XP and wasn't when I first read about it and lo and behold the second reviewer on that amazon page Craig Kenneth Bryant summed it up perfectly: "Barry Boehm once published a landmark paper on software defects, relating when you find them to how much they cost to fix. He found that defects were cheaper to fix the earlier in the development process you found them, which should surprise no one-adding or removing a sentence in a requirements document beats the heck out of screwing up everyone's paychecks in a production system. But the interesting part was how much cheaper it was to change a program in analysis than in production-orders of magnitude cheaper. Boehm's data produced a very steep cost curve as the project moved from design to implementation and out to the field-the most expensive place of all. So, years later, along comes a methodology called XP and claims to flatten the Boehm curve. The cost of change is now constant across the whole lifecycle, say the XP evangelists. It doesn't matter if we miss requirements up-front, or if we have to redesign the code over and over. Heck, it doesn't matter if you change your mind about the very nature of the system halfway through development. We're agile. Change is free. And how does XP work this miracle? XP's big idea is to scrap the analysis and design phases altogether, and get the code into maintenance as fast as humanly possible. In other words, XP flattens the Boehm curve by throwing out the cheapest segments of the curve, and spending the entire project in the most expensive segment. "
"110%" - it's the new 70%
John Cardinal wrote:
In other words, XP flattens the Boehm curve by throwing out the cheapest segments of the curve, and spending the entire project in the most expensive segment. "
Ah, but if it's a predictable cost... :rolleyes: (IT here is getting ready to scrap loads of software written specifically for the business for "off the shelf" software "customized" with "bolt-ons". Given what happened the last time they did this, i fully expect it to be a tremendous train wreck... but that may be just what they're aiming for.)
----
...the wind blows over it and it is gone, and its place remembers it no more...
-
That may be true, but is the inverse also true? That is, are those who mildly advocate XP, Agile, etc, better developers/managers? I think there are good ideas in XP, mostly around iterative development, i.e., design a little, code a little, find something you missed, refactor, redesign, code, loop until done. But the base process that has always been with us is essential: gathering and understanding requirements, and the desired results. It is also essential to understand how to get there. Without that firm basis, any "process", XP or otherwise will fail. In my experience XP doesn't help there and sometimes even hinders.
Silence is the voice of complicity. Strange women lying in ponds distributing swords is no basis for a system of government. -- monty python Might I suggest that the universe was always the size of the cosmos. It is just that at one point the cosmos was the size of a marble. -- Colin Angus Mackay
ahhz wrote:
That is, are those who mildly advocate XP, Agile, etc, better developers/managers?
No, though I recognize that several give lip service to it just to shut up the fanatics. There are managers/developers, myself included, who advocate things that overlap with the claims of XP/Agile, but that doesn't make us mild advocates. Even one of the main XP advocates rightly observe that once you pick and choose, what you have quickly ceases to be XP. The "little bit pregnant" phrase pops to mind. For example, even recognizing that software development is an iterative process doesn't count since this is true about any human endeavor. Change "refactor" to "edit" and "redesign" to "change a plot line" and you could describe writing a novel. This is actually one thing that irritates me about XP and Agile development philosophy (and most "methods" in fact)--they hijacked the obvious, claimed originality by changing terminology and then surrounded them with a bunch of nonsense. (The "design patterns" yokums did the same crap. They're called algorithms, but I suppose "design patterns" sounds so much more intellectual.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
That may be true, but is the inverse also true? That is, are those who mildly advocate XP, Agile, etc, better developers/managers? I think there are good ideas in XP, mostly around iterative development, i.e., design a little, code a little, find something you missed, refactor, redesign, code, loop until done. But the base process that has always been with us is essential: gathering and understanding requirements, and the desired results. It is also essential to understand how to get there. Without that firm basis, any "process", XP or otherwise will fail. In my experience XP doesn't help there and sometimes even hinders.
Silence is the voice of complicity. Strange women lying in ponds distributing swords is no basis for a system of government. -- monty python Might I suggest that the universe was always the size of the cosmos. It is just that at one point the cosmos was the size of a marble. -- Colin Angus Mackay
ahhz wrote:
I think there are good ideas in XP, mostly around iterative development, i.e., design a little, code a little, find something you missed, refactor, redesign, code, loop until done.
But that's not XP's invention, that's the waterfall development cycle from circa 1970 and it's what I use here. http://en.wikipedia.org/wiki/Waterfall_model[^] Where you iterate down, then start at the top again after release. Hmm...maybe I should say I use the Spiral method as it's more closely matching what we do here in practice: http://en.wikipedia.org/wiki/Spiral_model[^]
"110%" - it's the new 70%
-
The Wizard of Doze wrote:
BTW, XP was refactored into 'Agile'[^] years ago.
I thought that Agile was base class (if you like) with XP, Lean and so on as the derived classes.
Upcoming events: * Glasgow: Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ... * Reading: Developer Day 5 Never write for other people. Write for yourself, because you have a passion for it. -- Marc Clifton My website
Colin Angus Mackay wrote:
I thought that Agile was base class (if you like) with XP, Lean and so on as the derived classes.
I guess XP is dead. The books, articles, presentations, ... are Agile nowadays.
-
ahhz wrote:
I think there are good ideas in XP, mostly around iterative development, i.e., design a little, code a little, find something you missed, refactor, redesign, code, loop until done.
But that's not XP's invention, that's the waterfall development cycle from circa 1970 and it's what I use here. http://en.wikipedia.org/wiki/Waterfall_model[^] Where you iterate down, then start at the top again after release. Hmm...maybe I should say I use the Spiral method as it's more closely matching what we do here in practice: http://en.wikipedia.org/wiki/Spiral_model[^]
"110%" - it's the new 70%
John Cardinal wrote:
But that's not XP's invention
no, but it's an aspect of Agile or XP. With the proviso that the iterations are short (which is what I've done most of my career.)
John Cardinal wrote:
that's the waterfall development cycle
no, it's iterative development[^]
John Cardinal wrote:
Spiral method
spiral is an adaptation of the waterfall model, so it's not XP nor ID either.
Silence is the voice of complicity. Strange women lying in ponds distributing swords is no basis for a system of government. -- monty python Might I suggest that the universe was always the size of the cosmos. It is just that at one point the cosmos was the size of a marble. -- Colin Angus Mackay
-
This book[^] is a gem. A definite must read, even if you love XP. An exerpt from one of the reviews, which I thing is dead on: XP Refactored is the first book to seriously and deeply critique extreme programming. The authors poke fun at the excesses of extreme programming, of which, by the definition of "extreme," there are many. The book contains the best critique of the legendary Chrysler C3 project I've seen, including a good discussion about why it really is more myth than legend. The authors do a good job of countering Beck's claim that "turning the dial up to 10" is a good idea. Although it isn't the most enjoyable part of the book, the most technically interesting part of the book is the chapter on "Extreme Programming Refactored." The authors see a lot of value in the specific practices of XP; they'd just like to turn the dial down from 10 on some of the practices, reorganize others, and tone down some of the religion. Marc
Marc Clifton wrote:
The authors see a lot of value in the specific practices of XP; they'd just like to turn the dial down from 10 on some of the practices, reorganize others
This is why we don't do XP. Not that I ever had to worry, pair programming would never fly. Pair designing I do think is a good idea, so I asked for it. We are an agile shop, because the nature of the business is changing from day to day (someone just switched GPS units on me this morning and shoved a new format to me -- great...). That's just the way it goes. Not everything changes, though a lot does, and there is the possibility of mid-course reroute on every project. But extreme was too extreme.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
John Cardinal wrote:
But that's not XP's invention
no, but it's an aspect of Agile or XP. With the proviso that the iterations are short (which is what I've done most of my career.)
John Cardinal wrote:
that's the waterfall development cycle
no, it's iterative development[^]
John Cardinal wrote:
Spiral method
spiral is an adaptation of the waterfall model, so it's not XP nor ID either.
Silence is the voice of complicity. Strange women lying in ponds distributing swords is no basis for a system of government. -- monty python Might I suggest that the universe was always the size of the cosmos. It is just that at one point the cosmos was the size of a marble. -- Colin Angus Mackay
-
The thing with all these fads is that you should always keep your brain engaged. It's the same with OO as such. So many designs that just went overboard on inheritance because it was the cool thing to do.
Kevin
-
That may be true, but is the inverse also true? That is, are those who mildly advocate XP, Agile, etc, better developers/managers? I think there are good ideas in XP, mostly around iterative development, i.e., design a little, code a little, find something you missed, refactor, redesign, code, loop until done. But the base process that has always been with us is essential: gathering and understanding requirements, and the desired results. It is also essential to understand how to get there. Without that firm basis, any "process", XP or otherwise will fail. In my experience XP doesn't help there and sometimes even hinders.
Silence is the voice of complicity. Strange women lying in ponds distributing swords is no basis for a system of government. -- monty python Might I suggest that the universe was always the size of the cosmos. It is just that at one point the cosmos was the size of a marble. -- Colin Angus Mackay
> I think there are good ideas in XP, mostly around iterative development, > i.e., design a little, code a little, find something you missed, refactor, > redesign, code, loop until done. Ummm...did you miss an important word: test? Seriously, having used unit testing for the first time in a large project over the last year or so, I'll always write unit tests from now on if it's at all possible. I still can't get comfortable writing tests before code, but I'm convinced that if tests are written in parallel, or at least only lag a little behind, end result is better code (esp. encapsulation) which is more easily refactored and far more reliable. Now if only we can figure out a nice way to unit test our ASP.NET code?
-
Marc Clifton wrote:
The authors see a lot of value in the specific practices of XP; they'd just like to turn the dial down from 10 on some of the practices, reorganize others, and tone down some of the religion.
I and I have written a book? :confused:
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighistI enjoyed the book. For me the best insight was to point out how "interdependant" the practices of XP are. i.e. Can't refactor without unit tests, lack of design up front means more likely to have to refactor etc.. Useful book showing the pitfalls for people doing agile/xp I think.
-
This book[^] is a gem. A definite must read, even if you love XP. An exerpt from one of the reviews, which I thing is dead on: XP Refactored is the first book to seriously and deeply critique extreme programming. The authors poke fun at the excesses of extreme programming, of which, by the definition of "extreme," there are many. The book contains the best critique of the legendary Chrysler C3 project I've seen, including a good discussion about why it really is more myth than legend. The authors do a good job of countering Beck's claim that "turning the dial up to 10" is a good idea. Although it isn't the most enjoyable part of the book, the most technically interesting part of the book is the chapter on "Extreme Programming Refactored." The authors see a lot of value in the specific practices of XP; they'd just like to turn the dial down from 10 on some of the practices, reorganize others, and tone down some of the religion. Marc
A whole book on "When you take something to the extreme it usually becomes rubbish"? A sentence and some common sense would have done just as well. Specifications taken to the extreme are bad. Design patterns taken to the extreme are bad. Unit testing taken to the extreme is bad. Quality control taken to the extreme is bad. We use agile here and it works. We aren't religious about it (we adapt for every project) and we are always improving on the process. Nothing holy about it, we just want to get our jobs done better.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
A whole book on "When you take something to the extreme it usually becomes rubbish"? A sentence and some common sense would have done just as well. Specifications taken to the extreme are bad. Design patterns taken to the extreme are bad. Unit testing taken to the extreme is bad. Quality control taken to the extreme is bad. We use agile here and it works. We aren't religious about it (we adapt for every project) and we are always improving on the process. Nothing holy about it, we just want to get our jobs done better.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
Paul Watson wrote:
A whole book on "When you take something to the extreme it usually becomes rubbish"?
As compared to the dozen or so books on "when you take something to the extreme it comes out great"??? Yeah, I think we needed one of these. :)
Paul Watson wrote:
We use agile here and it works.
What's agile? I've heard it's XP refactored. :rolleyes: Marc
-
This book[^] is a gem. A definite must read, even if you love XP. An exerpt from one of the reviews, which I thing is dead on: XP Refactored is the first book to seriously and deeply critique extreme programming. The authors poke fun at the excesses of extreme programming, of which, by the definition of "extreme," there are many. The book contains the best critique of the legendary Chrysler C3 project I've seen, including a good discussion about why it really is more myth than legend. The authors do a good job of countering Beck's claim that "turning the dial up to 10" is a good idea. Although it isn't the most enjoyable part of the book, the most technically interesting part of the book is the chapter on "Extreme Programming Refactored." The authors see a lot of value in the specific practices of XP; they'd just like to turn the dial down from 10 on some of the practices, reorganize others, and tone down some of the religion. Marc
The Chrysler C3 Payroll project was a complete failure. However, this failure didn't make itself known until one year after everyone on the project made their marks with commercializing their new found ideas for "high speed" programming. "XP" or "Agile" programming are merely re-hashes of incremental and evolutionary development which are considered mature life-cycle models. The problem with these new approaches is that there is no such thing as speeding up labor intensive work that requires concentration, skill, and most importantly, time, to make things as close to high-quality as possible. Most software today that is seen as either bloated or bug-ridden is a result of bad project management with the expectation that getting things out the door faster will better their sales. In some cases this is correct but in the long term you get what we have today, an overwhelming amount of poor quality software. Now management wonders why...
Steve Naidamast Black Falcon Software, Inc. blackfalconsoftware@ix.netcom.com
-
This book[^] is a gem. A definite must read, even if you love XP. An exerpt from one of the reviews, which I thing is dead on: XP Refactored is the first book to seriously and deeply critique extreme programming. The authors poke fun at the excesses of extreme programming, of which, by the definition of "extreme," there are many. The book contains the best critique of the legendary Chrysler C3 project I've seen, including a good discussion about why it really is more myth than legend. The authors do a good job of countering Beck's claim that "turning the dial up to 10" is a good idea. Although it isn't the most enjoyable part of the book, the most technically interesting part of the book is the chapter on "Extreme Programming Refactored." The authors see a lot of value in the specific practices of XP; they'd just like to turn the dial down from 10 on some of the practices, reorganize others, and tone down some of the religion. Marc
I had my share of experience with XP with J2EE. The zealots that introduced XP to our organization, created an incredibly slow and beurocratic environment. They jumped ship eventually and the rest of us got canned due to lack of return on investment. Needless to say XP is not on my list of great innovations in software development. Marc A.