Extreme Programming Refactored - The Case Against XP
-
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.
-
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
Yes, you are correct there are many flavors of Agile. XP being only one. Extreme Programming (XP) Scrum Agile Modeling Adaptive Software Development (ASD) Crystal Clear and Other Crystal Methodologies Dynamic Systems Development Method (DSDM) Feature Driven Development (FDD) Lean software development Agile Unified Process (AUP) I don't think you can equate XP to agile. Many of these methodologies have varying degrees of the word extreme. The key thing is to find one that is a close fit to your needs, modify it to meet your needs and blast away.
-
I love the title :) Seriously, these buzzwords would be funny if they were not harmful. I was using "design patterns" when they were simply called "idioms" and there was no big deal about it. But once the GoF book came out and the "architects" started usnig them to add complexity to their flawed designs it really became bad. Maybe it is a time for a "Design Patterns Refactored" book? (yes, I know there is the "Refactoring to Patterns" one[^] already)
You seem to be contradicting yourself - "I was using idioms... was no big deal" and then you say "architects started using them to add complexity to their flawed designs" - when you were using them I guess you were no architect, but you obviously still added complexity to your own flawed design :sigh:;-) Patterns, planning strategies, even UMLs for that case are just there to try and bring "order" in a world of chaos (same as Economics X| ) Good architects don't need any of that and would run a project with their own methodology which none would mind if the project succeeds. Obviously in reality most SW projects fail, and the more analytic people among us try to "organize" and "suggest" the best way of doing things, which again cannot always be 1-to-1 applied to real life. Either, ignore buzzwords (except in Presentations) and always do what you feel is right. If it all works out you'll get a pat on the back, otherwise a methodology might be forced upon you... May the force be with you :laugh:;-) .leON.
-
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
This has not been my experience. I have known some excellent software engineers that advocate Agile development. The problem is that many people say they are using Agile development techniques when in actual fact they are just using the 'code like hell' technique with no design. There are aspects of Agile development that you can't leave out and still call it Agile - like unit testing for instance. Without the unit testing you can't refactor and without the ability to refactor you haven't got Agile. I would also say that Design Patterns are frequently applied overzealously. If they are making a design more complicated then they are being applied incorrectly. Once you've seen these techniques applied correctly you realise how beneficial they are. Applied incorrectly they cause mayhem.
-
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
I stopped following up IndustryWeeks webcasts when it decided it was a good idea to use the word "lean" in the title of all its new ones. A word that was making absolutely no sense to me, the definition of a buzzword. And I checked one of these broadcasts. There-was-nothing. I mean nothing that could define the difference of "leanness", what's new about it or anything.