Slashdot Mirror
Extreme Programming Refactored
The Previous Extreme - What XP Set out to Fix It had previously been accepted practice to spend months (years, even, on large-scale projects) gathering requirements, then another year or two on design, before a single line of production code had been written. The infamous "big bang delivery" occurred when this gigantic monolith of a software system was finally delivered to the customer, only for the customer to retort that this was nothing like what he wanted.
It was also accepted practice to divide the system into separate subsystems, and attempt to integrate them after several months. By this time, each subsystem would have taken on a life of its own, and integrating these disparate monoliths together gave a whole new meaning to "plug and pray."
How XP "Fixes" It XP takes the development process to the other extreme, by shortening the "waterfall" lifecycle to weeks, days, even minutes. In fact, Kent Beck describes XP as a "waterfall run through a blender." Iterations typically last for a week or two; there is a high emphasis on code quality via unit testing; and code is integrated "constantly" so that it never becomes out of synch with the rest of the project. Beck is often quoted for saying that the XP practices "turn the dial all the way up to 10" -- that is, if something is good (testing, integrating, pair programming etc), well then, let's do it all the time.
There's a lot to be gained from learning about XP, and agile practices in general. However, many feel that XP has taken things too far. By taking things to the opposite extreme, we're just introducing a fresh set of problems. The optimum solution, then, must lie somewhere between these two extremes. That is fundamentally what Extreme Programming Refactored (XPR) is about.
Optimizing the Process There's been a lot of controversy surrounding this book. It grew out of an equally controversial article that appeared on the author's website. XP advocates were arguing on Yahoo! Groups over XPR's good and bad points, miraculously, months before the book was even available. XP zealots were even posting messages telling others not to buy the book, before they'd even had a chance to read it for themselves and find out what it's all about.It's important to note that XPR isn't the anti-XP slam piece that some people had been expecting. It does rip into the XP practices in plenty of detail, but importantly it also describes alternatives, and talks about the good aspects of XP.
The authors make the argument that "turning the dial up to 10" mostly isn't such a good thing, and that to achieve our "holy grail" development process, we just need to turn the dial down a little bit -- let the milk simmer rather than boil over. We can do this by adding in some additional practices that take the burden off the overloaded, heavily interdependent XP practices.
For example, not everyone likes to pair program (with two people sitting at one computer). It just isn't for everyone. However, XP relies on everybody in the team pairing all the time. So if you don't like to "pair up," what choice do you have but to leave the project? XPR adjusts the other practices, placing a bigger emphasis on up-front design and documentation, so that pairing up doesn't have to be mandatory.
XPR also argues that it is possible to achieve a decent design before writing the code. The authors don't want a return to "BDUF" (Big Design Up Front), but instead to achieve an ideal middle-ground. The result is more akin to the monthly Sprints found in Scrum (www.controlchaos.com).
Similarly, XPR argues that the customer (and users) usually do have a pretty good idea what they want from a new system, and that they don't have to see a live system first before realizing that they wanted something entirely different. The authors argue in favour of interaction design as a way of achieving this goal.
XPR achieves all of this with more than a mild dose of satire. It's important to realize this -- the book is essentially "taking the piss" out of the more extreme XP practices, and the quasi-religious Extremo culture that has quickly grown up around XP. It has lots of serious things to say, but has a slight danger of that being lost "in the chuckles." There again, the danger is less to do with the book, and more to do with the reader.
XP sealots will never be swayed by such a book, naturally, but they are not the audience. It is for those undecided, or the cowed XP skeptics who know something is very wrong at the heart of the beast, but haven't have the words to say it. Even for zealots, I'd hope they'd put the hatred for long enough to at least temper their XP actions, to turn the dial down a little, to read the contents with the possibility in their minds that XP isn't the final perfect expression of all programming methodologies. Just for a while...
If you are scared of the contents, a favorite XP accusation, then of course you'll point out the 'needless humour,' blah blah, anything rther than address what the book says. Form will be far more addressable than content. It's the old "ignore this man, he wears a colourful tie" excuse, pick on some small detail that you feel is a weakness and totally ignore all the embarrassing questions you'd rather not address. If you like the contents, then the humour will be seen as a playful, court-jester like addition to what is a seriously analytical book
In conclusion, this book is well written, thought provoking, and above all entertaining (an aspect which seems to be proving almost heretical among some XP advocates). I found this to be a fun read, unlike some books, it was never a chore. It's extremely conversational, like having a cynical, wise-cracking guide. It's a pity more computer books aren't this fun. A spoonful of sugar and all that...
In fact this book is pretty damn wonderful. I know, it may sound a bit gushing, but before you review my review, give the book a read yourself. It's a thing of beauty, a rare mix of positive and negative, sweet and sour, opinion, and XP's favorite emotion, courage, courage enough to say "the emperor has no clothes." I can't see how you could read this book from beginning to end and not see XP in a different light.
In fact, XP programmers would do well to read this book, as it presents the negative path, something other than sunny-day scenarios. Using these warnings and guidelines, they'd have much more successful projects, as this book points out the dangers of lack of XP discipline, fragility and so on.
The truth is that I couldn't do justice to this book in such a short review. There is just so much evidence, so many contradictions pointed out, endless damning words from XPer's own mouths. It was supposed to be a small book to start of with, 150 pages or so, but due to the sheer body of evidence and submitted real life stories from those in the trenches, it bloomed to 400+ pages.
As Doug Rosenberg says "I don't want to be nearby when somebody decides to deploy an air traffic control system or some missile-targeting software that has been developed with no written requirements, and where the programmers made the design up as they went along." At least don't say you weren't warned!
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.
That's almost as bad as reviewing a book titled "Linux isn't always the answer."
here even.. sorry about that
I have over 70 freaks, do you?
I am delighted to see that XP has now been revisited and is being shown to not be the end-all of development styles. Perhaps with the slightly less "extreme" version, more managers will be willing to accept the changes. I have never had a boss accept XP, simply because they were scared of it (IMHO).
stuff |
The Previous Extreme is pure fantasy. It has been well known for a long time that big bang or waterfall models don't work well. For example see the Ian Sommerville Software Engineering book - it's mentioned the 'spiral' model (iterating out from the core of a small well understood system) for at least ten years. I couldn't read any more of this "book review" after such a bunch of nonsense.
Well, have you?
I'm about to start a project using pair programming (not exactly Extreme, but something like that) and I don't like it one bit
Pair programming is uncomfortable on our reduced space. And it's noisy.
Are the inconveniences worth it?
Kilroy was here!
I've read many books of this type but this one stands out. Its not just another "lets think of it in another fashion" book. Instead of just saying that "hey lets reinvent the wheel" it points out what is wrong with the "wheel". Its tells you the shortcomings of today's practices and most importantly, it describes how one can make programming a bit less tedious.
All in all, a great book.
XP and refactoring. Two over-blown buzzwords that go great together.
the customer (and users) usually do have a pretty good idea what they want from a new system
This a most telling quote as most developers have never talked to an actual customer in their entire career.
I think the next programming movement should be called XTTFC for Extreme Talking To a Fucking Customer.
sPh
That XP is just fashionable
Take that you XP sealot!
Dogma - "let's just say we'd like to avoid any empirical entanglements."
there are numerous factual erros on what xp is in this book..
One example..if using xp must pari program..
wrong! XP like any software process allows you take and use only those features that work with your project something this book author forgets to point out...
Don't Tread on OpenSource
Microsoft really outdid themselves!
I don't need no instructions to know how to rock!!!!
Reasonable, well thought out, non-extreme methods mean the terrorists have won. Oh, wait. That's a different article.
Anyway, how do you scream at the top of your lungs "MIDDLE GROOOOOUUUND"?
hey, the /. favicon's got a transparent background! W00t! (?)
/. code monkey dept?
Maybe a result of eXtreme Programming in the
The XP guys _have_ made a mark in the world. Now, how that is going to work out longer term, remains to be seen. XP _is_ influecing stuff like IBM's Rational Unified Process.
I tend to like XP. I haven't worked in an XP shop, but I have used it in class projects and some project of my own.
Right now, lots shops have processes that are non-existant or chaotic--that is what XP really needs to be compared against. XP isn't "the emperor" more like an upstart prince edging in on the territory of being eyed(but not governed) by Emperor RUP.
My gut is that was is motivating books like this:
is the fact that XP is being adopted in places where stuff like RUP just would never get a toe in the door in its present state.
The major stages of the opponents of an invention:
a) it won't work
b) its evil
c) its not really new
d) we invented it
This stuff strikes me as somewhere between stage a-b.
Sounds just as bad as windows XP
If there was a book called "Why Linux Sucks", and I contributed to it, and I agreed with it, would that make me a fair reviewer for it? You can find links to some possibly less biased reviews at softwarereality.com. It's also worth reading the comments on the Case Against XP article on the same site, by one of the authors of the book.
having a team of programmers who:
Like to program,
are properly trained and schooled,
who are paid enough,
and are given enough time to do the job right.
Everything else is fluff or a fad.
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
Get over your damn karma whoring. Every single post of yours is an alternate link. Having excellent karma is fine and all, but try posting some useful content in trying to gain it. You're not much better than the trolls and crap flooders. Think about it, and at least try posting some additional info with your links. Perhaps a 'this link is better because...' or 'the book is only $x over here and they ship faster'. NOT posted anonymously because I know this will get modded down and I want to make a point with it.
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
I would have like to have seen less of the pre-emptive rebuttal and more reviews on some of the findings and recommendations.
Drop the dogma and theology, and give us the hard core, nitty-gritty, down and dirty facts.
After reading the disclaimer "I should point out that I get a couple of small mentions in this book (the authors quote an email from me), and I also happen to agree with a lot of what the authors say. But I'll try to be as impartial as I can with this review." I was a little skeptical. It's pretty easy to enjoy a book that uses your ideas for content. I know it's not an entire book written around one e-mail but it's always a nice stroke to the ego to be found printable. That aside I think that although he did point out that the the writer is fair in his addressing the good and bad of XP and that the review is likely close to the truth, I feel as though the reviewer has taken more than great lengths to defend the book against the nay-sayers and "zealots". I'd like another review before running out to pick it up.
I have been using XP where I work for over a year now and I must say it is the worst enviroment I have ever worked in. It seems XP is for people who just want to write code and not think about serious design issues or future planning. In the future when looking for a job I will make sure that they DONT use XP. More and more it appears to me that XP is for the hacks out there that never bothered to learn how to do real design work.
Look,
.
Nobody should shun any alternative aproach to software development in favor of established "software development practices" when a huge percentage of projects, very very close to 100%, come in late and massively over budget
I'm one of those people who have seen XP tried and failed, and to be honest I never found it a suprise. I was educated to be a software engineer, and that the best way to deliver software effectively is to understand the problem domain. Iterative models like RUP or DSDM are great ways of delivering functionality quickly... XP is not... however there are some ideas in XP that are completely un-original that can work
1) Pair programming - first seen in the "Surgical Team" idea from the mythical man month
2) Unit Tests upfront - first seen in the 60s with the moon landing and space programmes.
3) Iterations - First seen during the 80s with the rise of object oriented systems
The ONE original idea in XP is simple...
You don't need requirements before you start coding. For godsake that is a friggin DILBERT cartoon.
XP assumes the John Wayne school of hacking, just hack hack and your talent will get you through. The reality is that if you are brilliant ANY process would be okay, and if you aren't you need more process to make sure you don't FUBAR things.
I loathe XP, its a strong word but to me it represents the Microsoft view of software in its documented form. Quality doesn't matter, it isn't engineering...
Its just lobbing together some-stuff.
I'm an engineer... what are you ?
An Eye for an Eye will make the whole world blind - Gandhi
I seriously doubt anyone will do that. In fact it's pretty likely people will opine on the book without having read either the book or the review! Are we going to see "RTFB" in book review discussions now?
Not only did the reviewer gush about the book, there was a little bit of gushing about the book's message (and bashing of its predicted detractors) that wasn't really informative about the book itself at all. It would have been better to devote more space to discussing what the authors actually said, so I'd have some incentive to read the book other than the satisfaction of seeing my point of view supported.
JCV
It's such that pair programming is SYNONYMOUS with Extreme Programming.
Every shop I've talked to, up to this date, about a job that did XP as their development methodology were strongly into the pair-programming along with everything else. I'm not sure WHY they seem to think that pair-programming is an absolute must with XP, but all the shops using it seem to think so.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
What XP Set out to Fix
XP set out to fix a lot of things.
How XP Fixes it
Unfortunately it fixed few of them.
-You may license this sig for only $6.99.
The real answer is somewhere in between XP and formal architecture. You need practical experimentation and you need design together to finish anything. A purely extreme programming environment would go around in circles without heading to a goal. A purely architectural environment would never get a practical solution.
When I hear XP, I always imagine big, swooping camera movements at weird angles with a big, flashy logo and an over-excited announcer for a guy debugging a double-freed pointer.
Its good to see some Impson fans out there ;)
"My shit always works sometimes!"
I cannot attest to actually having been involved in any project which used XP as defined but I can say the following about what I consider similar:
I used to work at a company that strangely enough fostered both getting things done quickly for some projects while fostering a long drawn out method for other projects.
The company was a consulting firm which always needed an answer yesterday for this or that problem.
They also wrote fairly large simulation packages for the FAA. Some of these projects would go up to three years. Lots of planning etc. was usually done.
Regardless of which type project I worked on I always tended to be the type who would get something working quick and then iterate over it several times if necessary.
Others tended to be going at what I considered to be a snails pace mode. They would plan for days, weeks, months on something that I never considered worth that much planning.
I could usually have a pretty good prototype working with a couple of major revisions made before the "planning types" could even get out a initial prototype.
But, over the years I noticed that I (and those like me) tended to get "officially finished" in about the same amount of time that the annoying guys who planned everything out to the Nth degree got finished.
Was my product any better than their's? No not really.
Which methodology was better? It's hard to say, I know I certainly always liked to utilize new methodologies that worked well while they liked to stick with the tried and true.
About the only thing that I can say is that my internal company clients usually appreciated that they had something to work with earlier rather than later.
They knew it was a rough version, but hey, if you need it now, you need it now. And two years from now may not pay the bills.
So, lots of times I came out looking like a hero.
But, looking back on it now I'd have to say that my own personal version of XP wasn't any better than my counterpart's long drawn out process, at least in terms of a final product.
My $0.02 worth.
Sorry if I was too far off-topic...
Caution: Contents under pressure
But "real design" doesn't work, at least, not very well.
"Real design," as you call it, requires that you keep to yourself, code code code in secret and hope what was defined in the beginning is still what the customer wants.
XP requires everyone to stretch beyond the "standard" development method. But for some reason, developers don't think they need to stretch.
The lack of future planning in XP is not a flaw, it's like that on purpose. I believe that hacking is the best most ideal way to code. XP facilitates hacking on a company wide scale, so even non-developers understand the progress being made.
A programmer is a machine for converting coffee into code.
XP, like any other process, fits some places and doesn't fit others. While some XP nut-cases may claim otherwise (just like people who market Rational products may claim that RUP should be used for everything), I've never seen the claim made in the pro-XP literature that XP was good for everything.
XP is appropriate for projects where:
Requirements are likely to change or are not well understood.
The customer is readily available
The team is reasonably experienced in the tools being used
etc
Air traffic control and missile guidence, while hopefully satisfying the third item up there, don't satisfy the first two. The customer is generally unavailable (I'm guessing here), and the requirements are understood remarkably well. Further, since these would be critical government projects, you wouldn't even have the choice to use XP. Heavy up front documentation is the only way to go on them.
Perhaps a better statement would be "I'd hate to be around when a major company decides to deploy an accounting system that has been developed with written requirements that aren't in the form I'm used to (user stories) and where the programmers modified the design to suit shifting requirements as they went along." Except, of course, that that is exactly how XP got started and it worked just fine (on a project that had previously been failing).
I don't think he want's to review his own book, that would mean too much reading. He's opting for the easier way out, which is to review the review.
So to continue the trend, I will review the review of the review:
I feel the author was self serving while complaining about the original review. Although this review may not have been a "New York Times" quality review, the substance of the book was aptly reviewed, making the review of the review quite useless.
---
Tomorrow we review the review of the SCO code by SGI.
I've been though a lot of XP. I feel pairing is one of the more crucial aspects of XP. In other words, if you don't pair, you're not doing XP. Make no mistake, pairing is not for everyone. Do you have a cranky,maverick,social misfit who writes brilliant code? Let 'em...don't try to force 'em to pair. Pairing works when a) the people want to pair, b) the people are socially compatible. Pairing forces you to code...no surfing or other dicking around. One coder grabs the keyboard/mouse and does some work, say throwdown a new class or method. Or, more likely, code the test class first. Keep going until you feel "empty" or tired, then pass the torch. The other coder watches and contemplates the code, and offers advise. They are an instantiation of YOUR coding conscience. Coding alone, you may say to yourself "fsck it..i'll clean it up later", but while pairing, the other coder's duty is to say "why are you doing it that way? How about this?" and so on. It has to be COLLABORITIVE, not COMBATIVE..although that happens. If you pair, make sure pairs are always rotating...don't let the same folks always pair. Keep the pairing times short...half day is plenty. Pairing helps to eliminate "hot spots" in the skill set...i.e. experts in one area. It will not eliminate it...people will naturally gravitate to the things they like. Pairing will tire you out, as you tend to "go hard" (==productive) for the day. I think some of the best code I've written was while pairing...if I factor in time spent/unit coded. I've written some brilliant stuff alone, but it took longer. REMEMBER: the other half of the pair who does not have the keyboard must stay involved...question the codier, try to find flaws. They are not just sitting there watching the other half. If you see a pair talking to each other and looking at the screen and pointing, and passing the keyboard back and forth, and just cranking...you've got a good pair. Pairing works, if the pairs work. read this too: http://www.objectmentor.com/resources/articles/xpe pisode.htm
> For example, not everyone likes to pair program
> (with two people sitting at one computer). It just
> isn't for everyone.
You know, there are places where pair programming is very helpful. It's part of the job. This whole touchy/feely "it's not for everyone" stuff is BS...it's for people who want others to work around their quirks. We're not freakin' artists, we're software engineers.
The web-posted material on which this book is based is not a thoughful critique. It is parody, yes, but not a critique. One of the central points made is that XP requires, e.g., strong unit testing and refactoring to work. Yep. If you don't do that, XP doesn't work well. Yep. These are points no XP advocate denys. The material ends up making the claim that if you don't do XP you can't do XP. This is quasi-interesting, if utterly obvious, but not the basis for a book-length attack on XP.
Skip this book and buy McBreen's if you want to read a critique. Join the Yahoo group and state your critique thoughfully, and read how some of the major thinkers in XP respond. Then make up your mind.
No, the people who hate pair programming are those of us who spend too much time reading slashdot every day!
No, it's not, the guy is in Michigan.
It's Slashdot user ih8apple.
I think Extreme Programming XP made some significant improvements over Extreme Programming 2002, but it will be better when the .NET framework comes in the box in Extreme Programming 2003
The "waterfall" was great for determining exactly what the user wanted but then ended up delivering it five years later after the requirements had changed.
"Use-case" analysis was great for determining how the user would interact with the system but tended to automate the existing processes instead of figuring out how automation could make the process unnecessary.
OO was great for implementing the non-reusable objects determined to be needed by "use-case" analysis (see previous item).
Too many shops implement XP as an excuse for not understanding the user requirements but just bashing out a bunch of high quality code that solves *the wrong problem* in a short amount of time. This isn't a criticism of XP so much as a criticism of the way it is misused (as has every other innovative software development technique).
The basic problem is and always has been that inventing the future is difficult mainly because the future has a habit of changing while we're busy trying to invent it. No technique other than a time machine will ever solve this problem because it is inherent in the invention process.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
Everyone I have come across in person who claimed to have used XP turned out to be someone who didn't have a clue.
On the other hand I know plenty of people who use what could be termed XP on daily basis, yet I doubt they ever read XP books or even care about it.
In general XP is a buzzword for the managerial types, the process described therein is pretty much common sense with a bunch of bells and whistles attached.
grisha.org
It's the same IP address as /. user ih8apple.
What a coincidence.
The subject is "XP Programming" which means Extreme Programming Programming. Oops.
When I hear XP I think blue screens. But when I hear Extreme Programming, I picture teenage kids strapping themselves to heavy gear and occasionally falling and scraping their knees.
Extreme Programming or Rapid Application Development is just an excuse to bypass solid process in order to ship faster. Does it do the job better? No.
General problems with the approach:
Design on the fly. You get less features, more hastily implemented. Code is less maintainable.
Without a plan up front, you have QA scrambling to keep up. Testing is full of gaps in coverage. Product is more buggy as a result.
The only real benefit is shipping faster. You make everyone work harder and get an inferior product as a result. I suppose Marketing will be happy with that as long as the customers will pay for it.
Personally, I prefer doing the job WELL, not just doing the job, but I seem to be in the minority in the development industry these days. I know a lot of engineers would prefer to do the job well, but go along for whatever reason.
Having been involved in development for about 10 years, I've seen product quality decline over the years. Products in general have become more complex, but defects have increased substantially. I'd like to see a lower level of defects maintained and value to customer in stability, reliability and functionality/features increased.
Call me a dreamer.
What do the programmers in India think of XP and pair programming?
My bet is they just laugh at the crazy Americans and say "No wonder we're getting all their work..."
> But "real design" doesn't work, at least, not very well.
Says who? Works pretty well for me. My team and I are generally *more* productive when we design *before* we code. Ever hear the saying, "Measure seven times, cut once"?
> "Real design," as you call it, requires that you keep to
> yourself, code code code in secret and hope what was
> defined in the beginning is still what the customer wants.
*cough*bull*cough*shit*cough*
A development *team* usually consists of a point person through whom the specs are communicated, an architect who puts together the high level system design (including interfaces if possible), coders who take their cue from the architect, and testers who make sure that the code meets the specifications - thus closing the loop. There is a LOT of communication going on there. However, your team is only as strong as its weakest link. I'll give anyone the boot who can't accomplish their job (as is all to often the case from "wanna get rich, but don't know how to program/test/communicate" kids coming out of school these days).
> The lack of future planning in XP is not a flaw, it's like
> that on purpose. I believe that hacking is the best most
> ideal way to code.
Dear Lord. You people are INSANE. When the f**k are managers going to stop hiring people who actually know more than themselves about programming? No self respecting manager should EVER allow juniors like this guy to decide how development should progress.
Javascript + Nintendo DSi = DSiCade
Is it just me or is half of the review just analogies that describe the word 'extreme'?
It's why Liberals need to listen to Rush now and then. It's why neo-cons should read Franken.
So anyone using XP who says "don't read this book" is probably delusioinal in several respects.
As another poster remarked, though, it's a bit annoying to read a review that does not include snips of key points and some analysis. This is endemic in /. reviews. Reviewers, please go look at the form of articles in the Sunday Book Review and follow it!
-dB
"It if was easy to do, we'd find someone cheaper than you to do it."
The trouble with XP, fast prototyping, and similar methods, is that they are too often interpreted as an invitation to program by the seat of the pants - that is to say, to hack. I've seen too much success with up-front design, received too much valuable advice from users before coding ever began, to abandon it. It's good to see a middle ground proposed.
>>>(an aspect which seems to be proving almost heretical among some XP advocates).
From the review I gather the reviewer really likes to call XP proponents 'zealots', doesn't like pair programming, and really likes the book... all for fairly vague or undisclosed reasons. I read the build-up of implied negative things about XP as a Straw Man fallacy.
Who cares if XP might not be as rigid or lacking as implied by the review? Does it matter if innumerable IT depts and s/w houses absolutely treasure the old ways of scheduling, implementing, and maintaining software? And that at least some of them are at least marginally successful? Immaterial! Can programmers ever figure out how to program on their own, or in groups, or in the project/company of the PHB? That's indeed a tough one, and it's obviously necessary to combat with some arbitrary, unquestioned ideology.
and how exactly did you determine his IP address? and did it ever occur to you that the IP address might be masked or shared on some corporate intranet?
> The lack of future planning in XP is not a law, it's like
> that on purpose. I believe that hacking is the best most
> ideal way to code.
This guy obviously hasn't adopted any of these projects where the previous programmer shared his philosophy. If so, then he would quickly change his tune.
This a most telling quote as most developers have never talked to an actual customer in their entire career.
"On-Site Customer" is one of the tenets of XP.. Of course, this isn't always practical, but having instant access to the customer is one of the things that makes XP work...
start with
1)Indication that the person writing the response has not worked with/read about/heard of the topic at hand. This is often implied and on many occassions is even explicitly provided.
follow with
2)A divisive and stongly held opinion based on reading the first line of the review and the mastery that only the previously mentioned lack of understanding can bring.
You're right. XP projects are incompatible with this. If none of the developers were on the original project, and the project is suddenly passed on to a completely new team, the project is pretty much toast.
The advise XP gives is to avoid this. If a new team is to take over a project, it should happen slowly and over time. If this is not possible, and this is my advice, not XP, the project should start over, using the original project only as a guide.
A programmer is a machine for converting coffee into code.
You know, sometimes we just want to pick our noses or read a news story on the web. Pair programming makes this impossible as there is always some idiot practically sitting on your lap. This is why it will always be perceived as punishment.
Pair programming attempts to take two mediocore programmers and create one decent programmer out of them. No senior developer is going to put up with some malodorous jerk sitting on his lap asking questions about every line.
> The advise XP gives is to avoid this. If a new team is to
> take over a project, it should happen slowly and over
> time. If this is not possible, and this is my advice, not
> XP, the project should start over, using the original
> project only as a guide.
Try translating that statement to dollars sometime and you'll learn pretty quick why that's not smart.
Javascript + Nintendo DSi = DSiCade
While the ad-hominen attack against the parent meta-review's author was on target, and the increase in the level of abstraction was intriguing (though not entirely original), this meta-review was too short to be informative.
I always thought that extreme programming was like, jumping out of an airplane with a laptop.
Oh well, another dream shattered.
Stem
"XP takes the development process to the other extreme, by shortening the "waterfall" lifecycle to weeks, days, even minutes. In fact, Kent Beck describes XP as a "waterfall run through a blender." Iterations typically last for a week or two; there is a high emphasis on code quality via unit testing; and code is integrated "constantly" so that it never becomes out of synch with the rest of the project. Beck is often quoted for saying that the XP practices "turn the dial all the way up to 10" -- that is, if something is good (testing, integrating, pair programming etc), well then, let's do it all the time."
It is funny, but this is exactly how my OpenSource development takes place - both for hobbiest and work projects. Only trick is that I am alone...
Te"Mr. BigInt"ls
Try translating that statement to dollars sometime and you'll learn pretty quick why that's not smart.
That's true, it's never smart to change teams in the middle of a project. There are always drawbacks to transition.
A programmer is a machine for converting coffee into code.
The big bang/waterfall thing was mentioned at the beginning of the review as the thing that XP was designed to get away from. *Yes*, it's generally been debunked as a method, but that doesn't change the fact that it is occationally USED, and it is the thing XP was designed to be as far away from as possible. Straw man or no, it is part of what led to XP being developed. Since at this stage in the review the reviewer is explaining the XP viewpoint and the things that led to it, this is a totally reasonable thing to be bringing up.
Well, wait, how about this: I don't think 'Absolutely' was a good first word of your title. Therefore I declined to read the rest of your "comment", and will declare you an uninformed, stupid troll.
XP reminds me of the way we used to implement our
practical assigments in University: weak design, start
coding with your co-team friend looking over your shoulder. Sometimes
very good results. But only because of very bright people I studied with.
Lots of backtracking and re-implementations. So expensive on you.
So, I'm sure I could google and read lots of confusing definitions, but would someone let me know if I've got this straight (I'm sure I'm not the only non-programmer here...)
Extreme Programming = You understand what the end product is supposed to be, you start coding, churn out a basic shell of the program, then just start to flesh it out untill it meets the end critirion
Non-Extreme Programming = You understand what the end product is supposed to be, you plan out what steps are required to reach the final goal, you plot out the structure of the code down to the individual functions, code each section individually, and then tie the code together.
Could someone let me know if I'm right or not? Once again, I'm sure I'm not the only one that is still atleast KINDA confused, even after reading the review and other articles about XP...
Sig.i>
http://www.armadilloaerospace.com
...could best be described as "Anguished chaos". Our boss (who is the only person who defines the requirements) changes what he wants on a daily basis, never gives a clear explanation of what he wants, issues bug reports like "Everything is broken!" and gets irate when something which you said will take two weeks is not done within 24 hours. Really.
Cress, cress, lovely lovely cress
Every time someone here said "I've seen XP, and it didn't work," the XP defenders say "what you saw wasn't XP".
Does that mean that a necessary requirement for XP to be XP is for it be successful? In other words, the failures disqualify a process from being XP?
Isn't that a rather self-fulfilling condition?
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
From my experience, customers only have a vague idea of what they want. They have a vision floating in their heads, but they do not have the technical know how or patience to put it on paper.
What customers do definately know is what they don't want. You can code up a user interface, and show it to them, and they can say no because it's not what they invision. It's hard to even get them to explain what they do like about the interface. They just know it's not what they want.
And that's from the smart customers. You can get basic requirements from them, and after 20 or so tries, a user interface that passes their vision.
From the general users, even that much is hard to get out of them. You can't even get them to explain what the current state of their software does. "Why do you even use it?" brings out blank stares. Or ask them how they use it in a typical day. I can't even get simple user stories, much less requirements and suggestions for improvements.
I'm ranting, but if anyone knows any suggestions for getting requirements and getting the customer to talk, I'd be glad to hear them.
Hey, redundant words are good enough for Microsoft!
The "NT" in "Windows NT" means "New Technology".
The Windows 2000 startup screen says, "built on NT technology".
Thus, we have, "New Technology Technology".
Whee!
Managers who will let the programmers get on with the job
Corporate structure that will let the management let the programmers get on with the job
Don't let THEM immanentize the Eschaton!
First waterfall....then XP Extreme.
;-)
.NET, Linux, XP or any other kind of zealots.
Maybe the answer is for the pendulum to swing back to a more "middle" position, which is where reality tends to reside?
Hmm....the review of this book coupled with the precepts of the book itself would seem to presage the swinging back of the pendulum to a more "reasonable" position.
'Bout time if you ask me. Not that you did...but having used custom processes that incorporated parts of Waterfall, Scrum, XP, Agile and more,
I've never liked the "one size fits all" pronouncements of zealots. Be they Java,
The answer is usually 42. How it applies depends...
Chaeron Corporation
> XP relies on everybody in the team pairing all
> the time. So if you don't like to "pair up,"
> what choice do you have but to leave the
> project?
Here's where my eyebrow first raised. Pair programming is an important part of XP, but not indispensible.
If your ego or work habits are so inflexible you can't bear even to try pair programming, then indeed you should leave the project. But then, you should have left a long time ago because you're probably already not communicating well with the rest of the team, or sharing code or ideas, etc.
> XPR argues that the customer (and users)
> usually do have a pretty good idea what they
> want from a new system.
Here's where I decided not to read the book. There are a few statements you can make that demonstrate you have little practical knowledge of software engineering in the real world, and this is one of them.
If coffee is good, then drinking it constantly must be great! Turn the knobs to 11! -jk :-)
You mean they cant suddenly decide to outsource the project to India? What a pity ;)
Stressing "customer satisfaction" is a good way to get a crap product. This echoes the attitude heard from Windows apologists: "Yes, but it's good for people who don't want to learn a lot about computers." For customers to have much input into the programming process is bad even for the customer. This is like letting managers overrule engineers in the Shuttle program.
Extreme Programming sounds like a way to pander to the egos of customers who want to "play computer", suits who think they know something and don't. Managers aren't programmers, they don't know how to program, and they should stay the hell out of the programming process.
mods metamodded as "Unfair"
You're wrong...it's this guy:
Anthony Martin, (310) 532-8393, 17450 Van Ness Ave, Torrance, CA 90504
XP is soooo waaaay old school.
Unfortunately, two mediocre programmers yield nothing but crap code. For pair programming to work well, the two would have to be very balanced with regards to each other's performace, or else there will be more work done by one or the other.
No "sane" senior developer is going to let a junior programmer coast along on the same coding task without doing his/her fair portion of the work. I find that it to be a waste of time to have someone standing there watching me code unless I am intentionally trying to demonstrate or teach. (Especially the boss!)
Besides, the parrot should sit on its own perch...
No self respecting manager should EVER allow juniors like this guy to decide how development should progress.
Unfortunately, most managers were either junior programmers who weren't any good at it or non-programmers with MBAs.
Healthcare article at Kuro5hin
Beck is often quoted for saying that the XP practices "turn the dial all the way up to 10" -- that is, if something is good (testing, integrating, pair programming etc), well then, let's do it all the time.
Nigel: "All the numbers go to 11..."
Director Marty Dibergi: "I see, and most amps go up to 10. Does that mean it's louder?"
Nigel: "Well, it's one louder, isn't it? You see, most blokes will be playing at 10...you're on 10 on your guitar. Where can you go from there?...Nowhere, exactly. So when we need that extra push over the cliff, you know what we do?"
Marty: "Put it to 11."
Nigel: "Exactly. One louder."
Marty: "Why don't just make 10 louder and make 10 the top number and make that a little louder?"
Nigel (chewing gum, pauses while he considers the question, then states confidently): "These go to 11."
Karma: Chevy Kavalierma.
Ahhhhhh, spoken like a developer with some real experience. Folks can read their "1 minute manager" programming books all they want, but most seem to be from the same snake oil vendors as the self help Dr. Phil books.
The reason software development works the way it does now is that it has evolved over time. We, as developers, learned the hard way that you have to have detailed specs (which don't take a year to derive) for several reasons. Mainly, so everyone is clear what the program is supposed to do, and how. Also, however, it's a tool to help avoid scope creep, which can bring a project (and budget) to it's knees. Avoiding that step, or compressing it into "hours" can be disastrous.
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
Which is required for any piece of aviation (including spacecraft) flight control system that is not on an experimental plane.
It doesn't make for the stringent design specification requirements, let alone a few others.
I definitely do NOT want to be flying on a plane or having one fly over my head that doesn't meet the DO-178 certification.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
If you read past the title of any XP book, you should come across principles such as Testing, Coding Simply, and Refactoring. If you still can't manage to write maintainable code with those practices in place, might I suggest a different career?
how to invest, a novice's guide
Everyone out there should buy this book and give extreme programming a try. Once you try it, you wont ever go back to normal programming again, i guarantee it!
You only read the title, didn't you?
someone had to smack down UML. XP was the
one to do it. It didn't matter who did it;
one would have been invented. Might as well
call it "eXtreme" and throw in buzzwords
like "refactoring".
Slight correction. This:
> When the f**k are managers going to stop hiring people who actually know more than themselves about programming?
Should read:
> When the f**k are managers going to start hiring people who actually know more than themselves about programming?
Javascript + Nintendo DSi = DSiCade
Unit testing, especially as a foundation for refactoring; continuous integration, read hourly builds; and the flexibility to revise design decisions when the need becomes obvious -- all of these principles are absolutely indispensible in any modern software project. Failing to do any of these things is an outrageous, inexcusable lapse. But these ideas are better understood and more obvious now than they were before Kent Beck came along with XP.
I see all the other posts in the thread so far claiming that some or all of these concepts were known earlier, before they were emphasized by XP. But that does not discredit the approach. Frankly, there's rarely anything new under the sun, but sometimes someone has to come up with a kind of philosophy just to help us realize how effective certain ideas can be. I think all programmatic software methodologies are like this -- they try to emphasize methods that are known to have worked well in the past, and try to draw useful generalizations about them.
Nowadays, most of the UP people are adopting many ideas emphasized by XP -- I attended a tutorial by Craig Larman last year in which he argued that no conflict between the UP and XP exists at all. But no one was saying these things before XP was articulated.
Incidentally, I think it's clear that the waterfall is an unmitigated disaster. I was once in a project that was managed that way, a big fat loser of millions, the worst nightmare of my career, took down a whole dot-com agency. Those were the days.
I don't agree with all of XP -- a complex system has to start with a fairly sophisticated analysis and design (but it better be designed flexibly enough to change over time if necessary). And I can't imagine pair programming, never tried it and don't want to. But even if the Emperor is not wearing purple and crimson ermine minks with linings of silver and gold, he's not naked either. On the contrary, his suit is fairly presentable.
Always keep a sapphire in your mind
The IP address is irrelevant. Try doing some elementary detective work. From www.ccats.com, follow the link to his eBay site. Lo and behold:
This page is maintained by ih8apple (105)
Not so hard, now is that?
In my view, the underlying problem with XP is just how extreme its proponents have let it become.
The original inventors of XP were very careful to say how they thought it was and wasn't useful. Kent Beck's "white book" gives a good list of "don't use XP if..." criteria which should have ruled out the near-disasterous project at where my company used it. As you point out, Martin Fowler and others offer different perspective, and nearly all the inventors insist on remaining flexible in the process and open to change.
The problem is all the zealots who picked it up and ran with it, taking it to hysterical, almost religious extremes: "I hated developement and was considering a career switch until I started using XP. Now I'm happier than ever, and so is my boss!" User testimonials sounded more and more like ads for penis enlargement, or rehab.
And what did XP's founders do to deserve this reaction? I mean, it's not like they oversold XP and tried to turn it into a cult...er....
Well, yeah, actually, that's exactly what they did: they set it up like a cult, and got a cult-like following.
The attitude of the XP literature is all too often overwhelmingly arrogant, self-important, marketing-focused, and insufferably holy-holy -- starting with the XP "Bill of Rights", and Kent Beck's inconceivably cocky advice on using XP. (Use it on your hardest project. Repeat.) Or Martin Fowler's laughable quote about JUnit: "Never in the field of software development was so much owed by so many to so few lines of code." JUnit is OK, but give me a break, Martin!
It's not hard to trace the cultural history of XP from these kinds of statements to the stories I've heard from colleagues of being the victims of angry attacks at conferences for asking about where the process had failed for them, or suggesting changes.
I think there are a lot of good ideas in XP, and I'd like to see the XP community fix its attitude problem so that those good ideas can prosper and evolve. Perhaps this book is the dose of circumspection that XP needs.
You're welcome.
so, you're dumb enough to assume the same person has the same userID on all the major sites on the net?
The unfortunate thing is that most reviewers have lost all sense of reality. One would think a 5-star review represents a classic for all time--maybe something on par with Shakespeare, or (dare I suggest) Design Patterns. A one-star review represents something absolutely worthless and/or dishonest, like the half-made-up Bellisiles' book "Arming America."
Extreme Programming Refactored is neither a classic, nor is it a complete waste of money. There are some good insights in the book, as it points out some of the pitfalls in the application of XP. It is for the most part well-written, but it also resorts to cheap shots and name calling. There are some serious problems with the book as well, including incorrect information and ignorant testimonials.
Most honest people would agree with this assessment of the book. Unfortunately, the bulk of the reviewers aren't. Honest, that is. XP haters rate it five stars, XP lovers rate it one star. [I fall on the pro-XP side of the fence, in case you cared.]
Even big-process bigot Steve McConnell chirps in with a 5-star review. Gosh, Steve, does that mean you think the book is a software development classic, on par or even better than your book Code Complete, which only gets 4.5 stars on average?
In any case, I did write a review of the book at Amazon, complete with quotes and such, and I didn't give it 5 stars, nor did I give it 1 star. But I guess my review sucked, because McConnell's review got more happy-popularity-votes than mine did.
Looks like somebody really enjoyed the taste of the author's meat popsicle. When the author comes up for air could somebody point him to amazon, they have plenty of useful reviews there.
> But "real design" doesn't work, at least, not very well. >Says who? Works pretty well for me. My team and I are generally *more* productive when we design *before* we code. Ever hear the saying, "Measure seven times, cut once"?
What we are missing here is the context. If you are working in a domain where you have already delivered 17 systems just like the one you are working on, then you can decide on the design up front. (As an aside, in that situation you should really just take a previous system and make it generic. That will pay off the third time you use the generic system.)
But if you are in a domain that still has unknowns for your team, it is hard, (how hard depends on the density of the unknowns) to do a decent design (or spec!) up front. You will fill the unkowns with assumptions (sometimes without realizing it). And the assumptions are often wrong.
So in a (small!) document-heavy development, you can expect to spend at least 40% of your effort in planning, requirements, architecture, and detailed design. And still wind up needing 35% rework. One of the nasty traps of document-centric development is that you don't know which representation of the system is canonical. If the code doesn't match the spec, which one gets changed? In a perfect world the spec is right and the code should change. But I've seen too many cases where the coder realized that the designers really didn't understand this business process and asked for something impossible/stupid/silly. So you jump through some hoops to decide to change the spec, and then jump throuch more hoops to actually change the spec & architecture & design. Which costs about 10 times what the code cost. And it holds up progress on the code while the changes are approved.
> I believe that hacking is the best most ideal way to code.
Then you don't know much about industrial-strength software development. Or XP. XP is a high discipline methodology. Test Driven Development (TDD) is a discipline. Merciless refactoring is a discipline. If you don't do them, you fail. Not requiring documents that (in the XP view) don't contribute as much as they cost does not equate to hacking.
When the f**k are managers going to stop hiring people who actually know more than themselves about programming?
Well, it seems to me that most managers I know only do that by accident.
Nobody needs prima donnas, of course (well, except ballet companies, I suppose ;-)
:)
Not this prima donna
Sorry, OT, couldn't help myself
.sigs are for post^Hers.
and you're also dumb enough to assume that the ccats.com is owned by the guy who has the ccats-20 referral ID? What about the other ccats copycat referral IDs? dumbass.
timothy should also point out that he lives at home with his mom.
My team and I...
You don't consider yourself a part of your team?
Ever hear the saying, "Measure seven times, cut once"?
See, this kind of thing is what XP addresses. "Measure X times, cut once" applies to WOOD. You know, a physical thing that can only be cut ONCE. Software is not wood. You can cut it again. And you will after the customer changes the requirements (or "clarifies" them).
I'm not saying you can't start without a design, it's that the stuff I was taught in school about big design and flowcharts and UML diagrams are more like what you need to do with hardware. Software can change. Don't fight it.
And of course not ALL software can be "hacked" together (maybe a bad choice of words by the grandparent).. I would never use XP practices on a database schema, or a real-time system, or anything with a hard spec (and no, most customer requests for a web app, shopping cart, etc., are not "hard specs").
If your development team can function with big-design-up-front, then fine, keep doing what works. I have found that with programmers of moderate skill with a few experts in the team, XP practices work best. ESPECIALLY the test-first design. That is the best part of XP IMO, once you realize and internalize that every line of code you write should exist to pass a test.
... and sleep deprivation is dangerous to your health. Sure, if 10 is "normal maximum", turn the dial somewhere around 42 or 78, but keep it there for a night or two, then deploy damned thing and get a month off, somewhere in mountains or on a ranch.
From company's point of view, an employee is like CPU, can be overclocked to 12-14 or so, add some extras, a cooler or a bonus and when it burns, just replace it. Not quite the employee's favourite idea though.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
That's a rocket, not a spacecraft. It's in the air for a few minutes, at most -- not on say a multiyear trip to the outer solar system or even a multiyear stay in GEO.
Plenty of rockets do just fine with no software at all, I've launched a few of same myself.
-- Alastair
A very good point... it's interesting that many of the same people who argue against Extreme Programming being sloppy are also the sort who are die-hard supporters of the Open Source/hacker methodology of development. If it's so bad to adapt the code as requirements change, how many Open Source projects follow a large formalized design document as opposed to accepting useful patches as they come up?
/when it works/, but it's very easy for it to fall apart, and then it is more harmful than helpful.
/really/ works. But if you throw the balance off slightly, if you can't have all the prerequisites for XP, it rapidly becomes more frustrating and damaging than normal development methods are.
/whole/ company being the big one.
However, there's a lot more to XP, and there are some definite weaknesses in it...I say this as an XP supporter. I'm also going to make the same argument I've made in most of the previous XP articles on here; XP is absolutely great
I was part of an Extreme Programming team that saw both ends of the spectrum. We had internal support, we met with our customer every two weeks and had an iteration planning meeting, and we were productive beyond all reason. When the requirements for part of the project changed, we were able to adapt quickly; our code was small, reusable and modular, so we were able to quickly make adaptations when the end-goal target changed. The code was largely bug-free because of pair programming, where one would work on design while the other coded, and we caught errors much more easily. Meetings were held standing up so that no one wanted them to go on for too long, and it kept them short. Our team was responsible for our own hires, which meant we picked folks who could fit into the pair-programming model well. We took a break every two hours to keep from burning out, we had separate 'personal' spaces as opposed to the pair programming computers...
It was one of the most rewarding development experiences I have ever been part of. Every bit of glowing, golden praise I had heard about XP working well seemed to be true.
But things changed inside the company when management changed hands. We lost the support for two-week iteration planning meetings, and had to work in six-month intervals. We lost the ability to hold stand-up meetings and were stuck in long conference calls. Our team got too large and fragmented into smaller bits, and the pair programming model broke down. Trying to stick to XP became an exercise in frustration and warfare with management. And as we let go of bits and pieces of XP, under pressure, the remaining pieces were weakened. Iteration planning only works if you can actually interact with the customer at an iteration-level, for instance... and so our targets became less easily defined since they were set out months in advance. Made it easier and easier for specific people to concentrate on tasks than having to swap around per-session... which ended up meaning instead of knowing all the code as we had before, anyone able to take over any area, we became specialized in specific areas of the project. And so on...watching XP collapse around us. And it was depressing, really, to see what had been a productive, active environment be stifled.
So that's my first-hand experience. When XP works...it
And more and more, it's harder to find the support for the XP procedures in a corporate environment. Bits and pieces that are in XP -- such as making modifications as they're needed rather than trying to plan overly far ahead for goals that might change, or writing test-suites for your code, and making clearly-understood code -- are of course sensible procedures. But the overall conglomerate only works if you have certain things...support within the
--Rachel
But "real design" doesn't work, at least, not very well.
It works as long as you don't have morons for designers. Software design is an expertise, and as such includes benefits of experience. Lacking the expertise and experience (or the budget for it), some will instead attach to a dogmatism, a "one true way" which is always correct in lieu of any expertise or lack thereof.
What many XP-ers don't realize, is that many of us have lived through previous incarnations of "one true way" software development dogmas and have come to recognize the signs.
There are similar problems in other professions-- Teacher for one example. Rather than trust a teacher's own education and experience, it has become the fashion to instead impose some dogma which, as usual is designed to take all the mediocre-to-poor performers and at least have them channelled into all doing the same thing. Frankly, I'd prefer to see teachers as professionals who bring something besides warm bodies-jammed-into-one-size-fits-all-methodologies to their profession. I think professional associations and credentialing for teachers like doctors and lawyers have would do far more to improve the quality of education, but it wouldn't be particularly cheap. In my book though, you may just be getting what you're paying for...
XP, like those dogmas before it, is designed to take a group of young, aspiring and inepensive programmers who don't know any better, have a huge amount of enthusiasm but the attention span of a flea, and give them focus in order to exert some common direction and control over their productivity. The XP methodology is a specifically defined and fixed target and not itself an example of it's own design methodologies.
I'm not sure WHY they seem to think that pair-programming is an absolute must with XP, but all the shops using it seem to think so.
Because it works, for several reasons.
First, with an approach like XP (or the somewhat looser Scrum), you're pretty much discarding the conventional design phase and everything that goes with it, like design documents. That means, other than the code itself, there's no "institutional memory" of why the code is the way it is, beyond what's in the memories of the programmer who wrote it. Documented code helps, as do code reviews. Think of pair programming in this sense as a very intense design and code review rolled into one. (This also ties into the skills transfer mentioned in another post).
Designing, moreso than coding, is easier if you have somebody to bounce ideas off of. You can keep each other on track, or come up with an approach the other hasn't thought of. Witht the XP approach you're doing some of the design work at the keyboard while programming -- so better to have two of you.
More subtly, but perhaps most significantly, it promotes team-building, especially if you pair with various team members rather than the same person all the time. This is not just a fuzzy feel-good management thing. Barry Boehm, who literally wrote the book on determining the costs of a software project, found that the largest factor, by far, in a development team's success is the quality of the team. (This after factoring out things like language or application experience.) Pair-programming (and XP) works because it helps build good teams.
There are other ways to achieve that, of course, which is good because XP is not suited to all domains. But I think that's a factor overlooked in the analysis of why it does work.
-- Alastair
Says who? Works pretty well for me. My team and I are generally *more* productive when we design *before* we code. Ever hear the saying, "Measure seven times, cut once"?
Having done things both ways, I'd say that incremental design improvement is the way to go.
Having done XP for a few years, I spend about 20% of my design time up front, about 30% while coding, and the rest while refactoring.
I like this a lot more than trying to do 100% of the design up front. Why? Because your design is only as good as the information you have at the time you do the design. For non-trival projects, it's impossible to have all the information you need up front; even if users never changed their minds once they saw the result (ha!), any good developer learns things as they go.
It also turns out to be much more productive. If I have to do all my design up front, I'm much more likely to overdesign; much better to have too much than too little. But if I do my design on a just-in-time basis, I can avoid a lot of needless work.
And as a bonus, my designs end up being better. The product may be version 1.0, but because I've been iterating over my architecture along the way, the architecture is version 5.0.
By Grabthar's hammer, I will avenge your first post...
Amazon Link:
here [Amazon.com]
PS I think we're posting frosty piss so fast, our URL's have gone sour!
You forgot another over-blown buzzword: Java.
Less is more !
It works as long as you don't have morons for designers. Software design is an expertise, and as such includes benefits of experience. Lacking the expertise and experience (or the budget for it), some will instead attach to a dogmatism, a "one true way" which is always correct in lieu of any expertise or lack thereof.
But we do have morons for designers. XP is a great way to shove the responsibility for design into the process rather than force it to be flushed out in the beginning of the project where it's less likely to have form.
XP, like those dogmas before it, is designed to take a group of young, aspiring and inepensive programmers who don't know any better, have a huge amount of enthusiasm but the attention span of a flea, and give them focus in order to exert some common direction and control over their productivity. The XP methodology is a specifically defined and fixed target and not itself an example of it's own design methodologies.
Hey, whatever works to get the pack moving. But I think you're wrong about XP being a fixed target. Maybe in a given iteration of XP, that's true. But it undergoes changes just like it recommends project specifications do. Isn't that what this book is about, "Extreme Programming Refactored?"
A programmer is a machine for converting coffee into code.
I believe my review of the review of the meta-review of the review of the review can best be described in one word. WTFPWNED
And what's the deal with PIN numbers?
....VB with option explicit set to off!
Apologies to the previous Slashdot poster who originally posted the below text, but I though it was so on the mark that I copied and kept it. It bears repeating:
I've seen SO many of these come and go. You can never question them while they're in the ascendancy.
Stage 1 consists of proof by repeated assertion, and "case studies" that actually describe only how projects using the Methodology were _started_. Lots of detail on how managers and workers were organized and brought on board, etc. Anecdotal success stories where you cannot tell whether the success actually had anything to do with the use of the Methodology or whether they just had a good team that would have succeeded anyway, or whether it was just Hawthorne Effect. No clear evidence that _other things being equal_ using the Methodology instead of some other process actually has a beneficial effect.
Stage 2 occurs when a Methodology has been used in enough real projects by a real-world variety of programmers, then you start to see the articles that say "in order for it to work, you MUST have conditions a, b, c, d, and e." One of the conditions is usually the enthusiastic involvement of upper management. But, hey, if you have the enthusiastic involvement of upper management you can probably get ANY project to succeed. Another is usually the adoption of the entire methodology, no "piecemeal" approaches. Another is usually the provision of adequate training. No real-world project ever meets all these conditions, therefore no failed project using the Methodology is deemed to disprove its efficacy.
Stage 3 occurs when people start to notice that the Methodology doesn't particularly work. Well, actually, it's never phrased that way. Nobody ever _admits_ that the Methodology was a fad which has now been abandoned. Instead, they simply say they are adopting the _new_ Methodology, which it is said, DOES work. Or at any rate WILL work. Provided, of course, that you adopt all of it, have the enthusiastic backing of upper management, and adequate training.
...and what's with "The La Brea Tar Pits?"
"...as most developers have never talked to an actual customer..."
True. But usually, an open-source developer is his own customer.
Thank you very much
By suggesting that XP is hacking, you've done damage to the XP community.
XP is most definitely not hacking. XP does not suggest coding without considering design. In fact, XP means designing each and every step of the way, redesigning as (if) necessary, and ensuring that the design is not only testable, but tested (frequently).
That's as futile as trying to create a diciplined heavy metal band or porn star. It defeats the whole purpose of having a Hacker in the first place.
The correct way to use two Hackers is to appeal to their ego. Have both code the same piece concurrently, and let the best code win. That way, you both ensure that the coders do their very best, and you also get alternative backup code BEFORE a problem is reported, which is invaluable in troubleshooting. Program crashes with both pieces of unrelated code? Chances are the problem is elsewhere, or with the specs.
Oh, and you can use this competitiveness to your advantage with QA too -- encourage the coders to find problems with each other's code. If possible, keep the programmers from even seeing each other (it's easier to slam the code of someone you've never met), and don't penalise the coder who creates bugs, but reward the finder instead.
THAT's extreme programming. EP, for people who can both code and spell.
Regards,
--
*Art
There is an interesting interview between Alan Cooper and Kent Beck at http://www.fawcette.com/interviews/beck_cooper/def ault.asp
Cooper was testing his ideas on goal centered design through his "Design+Fun" workshops. I offered up the opinion to Alan that software design is a bi-directional search: with firmware on one end and wetware on the other end. Alan and Kent start from either side of this search.
From XP, I gather that there is much exploration of the domain of APIs to deploy a solution. Writing code immediately helps document the search in such a domain.
From Goal centered design, there is much exploration of the range of a customer's goals. Writing designs helps document the search in such a range.
Using both: Goals help prune unnecessary features, while XP helps prune unrealistic expectations. While using either method could get the job done, perhaps using both is more efficient.
I don't care if it's structured programming, OOP, Smalltalk, Java, RAD, use-case analysis, XP, or XPR... no language, tool, methodology, or management style can provide a quick fix for the difficult problems of organizing, designing, implementing, and maintaining a significant software project.
By all means, read this book (or any other) if you feel it might bring something positive to your development process, and adapt what you can to your own project. Just don't fall into the trap of thinking that XPR (or anything else) will solve all your problems, and if it doesn't that you must not have done it right.
Conversely, those who've seen that, or think of design that way, think that it's completely unnecessary and diving directly into coding, using a flexible method, is the way to go.
I think that good design is nothing more than what needs to be done anyway. You've always got to spend a few minutes thinking of what you're going to do before you hit the keyboard. A good design process should simply mean that you pause for a minute, write down those thoughts you're thinking anyway, and then continue. No more detailed than needed.
The most useful part of necessary design work is that it's higher level than code (obviously, otherwise you'd have just coded it), and lets you consider more of the system at a time. Often if you code something that's simple, and then coded something else, you'll find when you need to connect them that there's something you hadn't thought of, so you need to rework what you did ("refactoring" that's such a big XP thing). If you'd taken the time to describe what you intend to do (as if an email to someone), chances are you'll notice the problem when you get to writing that sentence. It saves time because you haven't done any work yet, and it's a lot easier to change a few sentences than rewrite working code.
If you get used to doing this, you can get comments for free - take the description, and paste it into your code editor. Take each step and break it down for more detail - at some point it's so detailed, any more detail would mean actual code. So wrap the description in comment markers, and write the code between them.
Obviously some things need more design effort than others. There's no use being dogmatic about it - a good design policy shouldn't add unnecessary work (if it's unnecessary, why the heck are you told to do it?). An added bonus, if you get good at doing this, you can farm the coding of parts off to junior programmers.
There are several things you can use a design for. First (and most important, I think) is implementation - as I said, the thinking process that has to happen anyway, and communication to others working on the program. If it's easier for you to see where parts of your own module don't fit, it's going to be a lot easier for two people to get an idea of how their modules will need to work together if they can describe it to each other before hand - everything from whiteboard notes to email, even if not a full design, is better than nothing.
Helping someone later to understand the program (for maintenance) is only secondary. This isn't a good thing to rely on, since the design usually gets a little out of date compared to the implementation, but it should be a useful guide for someone looking at the code. The important thing is, it can only be useful if it's not too detailed - the details are where the design becomes deceptive when it differs from reality.
If a design is to be used this way, it should be updated as easily as the code - possibly more, and at any point after the fact.
I like au pair programming
We need Extreme programming because, come on guys, lets face it, normal programming is cutting it anymore.
That's completely false. What's not cutting it is the quality of today's programmers -- a lack of maturity, a lack of attention to detail, a lack of "doing it right the first time", a lack of using the right tool for the job (because language X can be used for *anything*), etc.
XP is a joke and always has been. It's just a rallying point for slackers who want an excuse for their wild, maverick, no-rules approach to software development...
Having "the knob turned to 10" gives you a sense of what pair programming is like. After a week or so at 10 you can't hear much and so it goes with code reviewing. Watching someone type is one of the most boring things to do after watching grass grow. After a while you lose focus and start to drift off. I've seen it plenty of times with multiple partners. In some cases simple coding gets so boring both the person doing the coding and the person checking fall off. Switching between typing and watching only helps a little. Switching partners help a little also. At the end of the day though you start hating programming. That's life at 10.
You can though blame it for being extremely boring.
You sound like a good programmer. It takes some self reflection to understand what a lot of XP proponents don't which is different people have different styles of programming. With XP you can't have different styles. If you don't fit in you get fired. I did.
Call it a psychological defect, call it a mental block, call it what you will... I just cannot write anything with someone watching me. Doesn't matter whether it's code, documentation, an essay, a letter, or a postcard. Try and force me to do pair programming and my productivity will drop to zero.
Code review, on the other hand, I'm fine with. Test harnesses, formal QA, documentation, extensive commenting, frequent releases, UML, it's all good. Just don't look over my shoulder while I'm trying to create something.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
The response you are currently reading is sadly disappointing. It takes an already overdone joke and attempts to outdo the meta-joke by introducing self-referential deconstruction. The result is more than a little pretentious, and simply not funny.
The responses to the response you are currently reading predictably miss the point--though that can be forgiven, given the author's stylistic quirks. What is harder to forgive is the poor spelling and punctuation, and general lack of grammatical flair.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I read the sample chapter of the book and was astonished at how bad it was. It starts out quoting some prominent XP people who have made postings to Usenet where they have misspellings, peppering their quotes with "sic" (to try to make their post look stupid), then follows up with a shotgun blast from "an anonymous XPer". How is anyone supposed to take this book seriously?
I've worked on XP projects and it works really well for certain types of projects, notably business systems that are speculative in nature. And the proponents of XP do not say that XP is right for developing air traffic control systems.
Refactoring XP is not a serious study, it's a biased example of pseudo-scolarship at its best, or out-and-out character assassination at its worst. I read the Pete McBreen book and I think that one was a more balanced view of where XP doesn't make sense.
In my opinion, the basic flaw with XP is that it requires constant engagement from the business side. Ha! Has anyone known ANY business-oriented (Sales, HR, Legal, etc..) co-worker with an hour to spare every 2-3 days for the next 3 months on your IT project.
d dly-details-about-something-my-boss-wants-done-but -I-could-care-less-about" to the average middle manager.
Remembering, Refactoring = "Interrupt-my-already-overloaded-day-with-more-fi
I tend to like XP. I haven't worked in an XP shop, but I have used it in class projects and some project of my own.
Kindly refrain from expanding on how you handled the whole pair programming thing on your own; thanks.
It comes down to doing it in the most reasonable manner for any pair of programmers. Sometimes you can work in tandem, other times you need long breaks from the other guy.
You don't necessarily have to have one programmer literally looking over the other's shoulder-- in my experience, it's more natural and makes more sense to discuss the problem with the other programmer, work separately for a while and then meet again to go over the results.
In one case, another programmer (senior to me) was describing how he was getting stock quote information over the wire and handling the fractions using floating-point calcs. He didn't like the implementation or the performance very much, and while he was telling me this, his phone rang.
While he was on the phone, I looked over his code and a few minutes later when he hung up, I handed him an integer version. By working on the problem alternately, we came up with a better solution (and the senior put in a good word for me with the boss, saying I had "a good eye for optimization)."
It all depends on what you're used to and what you're willing to try as a fresh approach.
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
Sounds great to me. This just happens to not be pair programming and XP. You don't work separately for a while because if you do that the other person isn't checking your code. If they aren't checking your code you need QA. If you need QA then why are you wasting another programmer's time. Etc, etc, etc. I find plenty of things in XP that I like and have used for years well before the word XP came out. The problem with XP is it decided to make these things ridged and cranked up to 10. Some thing that was good in moderation has been made into an ugly way to manage software development. Hopefully pair programming doesn't keep the bad connotation that XP is giving it.
I have to admit that I've never tried XP (I worked as a programmer before it came along), and I've only read a little about it. You're right, my example is not XP (I didn't mean to imply that it was), but it is pair programming of a different kind.
Two programmers, working on the same problem, in the same capacity-- the essential point being that the code passes both sets of eyes before it goes out. In our case, it didn't have to be checked every 5 seconds; every 5-15 minutes was sufficient.
The principle is the same, but tuned to accommodate our working style.
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
They're doing more than tab-indenting, one of them is running out for Mountain Dew and candy bars. ( Sending the dumb guy out on a real mission, priceless) Seriously, getting the dude who knows how to hack some (gag) maxscript or perl or whatever (knows some syntax and hang-ups) to sit next to the guy who knows how to program *any* kind of data structure can really get the shit done right and in a quick way.
Perhaps not, but it does happen when you take someone with potential and a willingness to learn, and then apply proximity to skill and experience and let osmosis do its work.
Not every junior programmer wants to make that effort, but plenty do. A smart company will employ such people and train them properly: it's a much cheaper way of getting good results, it raises the standards across the industry by supporting the new starters who will be the senior programmers of tomorrow, and it gives both an incentive and a watch on the veterans to make sure they keep sharp. Basically, everybody wins.
Sure, if you hire monkeys this will never get them anywhere and will just be a drain on the senior guys. But that's true of any methodology you use. The moral of the story is to hire people with enthusiasm for their field and a desire to learn, and not the monkeys. If they cost a bit more, pay it; compared to the benefits to a development team, the modest rise in remuneration and occasional perks it will take to make your place stand out from the crowd are nothing.
(I should say here that I don't advocate "pure" pair programming. I do, however, believe in senior programmers being heavily involved in supporting the junior guys by various means, including variations on the pair programming theme.)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I don't think the principle is the same with regards to XP pair programming and what you describe. You don't check after 5-15 minutes in XP. The person pairing with you is suppose to watch all the time looking for errors. There is one keyboard. One computer. There is pretty well nothing else to do for one person in the pair except to look over the other person's code. The principle in XP is constant vigilance. Looking the other way for 15 minutes allows your partner to run amok. :-)
I think you are developing an agile style. I like agile methods. You are not doing XP.
An analogy with XP would be drinking red wine. Red wine is good for you. XP would say dial that up to 10 and drink a few bottles a day. XP drops the context that some things work well in restricted situations and just says you should do it all the time with everyone.
Imagine working with someone in your group that you don't really like and whose code while "right" doesn't look too good to you. Go ahead and pair program with them. If you are lucky maybe you'll change your opinion about them. If you aren't tough luck under XP. Now do the same with someone you do like. With luck you'll still like them at the end of the day. Some times people aren't compatible but can work together. With XP you aren't really suppose to pick and chose. If you do you lose out on spreading the code knowledge.
OK, I'll third this one. :-)
In a good team, people should feel able to ask their colleagues for advice, and should be willing to offer it themselves. It doesn't matter if you spend significant amounts of time helping others, or vice versa: overall, your team will be more productive. You'll also have much better morale in the group, because nothing saps energy and enthusiasm like staring at the same problem for hours without really seeing how to proceed with it -- particularly if, when you finally give up and ask someone else, they suggest a working solution in about five seconds. :-)
As long as everyone has a little courtesy -- don't interrupt someone who's obviously concentrating hard on something, or disturb someone during their lunch break -- this works really well. I've seen it in several places, all with the same sort of approach, and I'd prefer it to mandated 100% pair programming any day of the week.
BTW, the "one writes the real code, one writes the tests" approach is interesting, but I suspect misguided if that's all they're doing. If your test code takes as long to write as your main code, you should probably investigate better ways to test your code. Writing test code is both a drain on resources and a potential source of errors, and as with any other coding, you should do enough to do the job, but no more. It's worse than regular coding though, because it tends to be really monotonous, and it's very tiring for someone to do it properly for extended periods. If you can automate testing, or part of it, then that's probably a better answer.
If you're going down that road, you might also consider having a designated tools developer. Nothing makes development more efficient and less tedious like a good tool. I recommend having someone whose whole purpose (at least for this week) is to be available to other developers to put together all those helpful little build scripts, code templates, test data generators and so on, and to maintain or update those you already have. For a smaller team, where this isn't a full-time job, it can be done by someone also writing the test code (which is often a tedious job, so this helps to provide more interest) or by any other main coder on the team in exchange for reduced commitments in that area. Any way you look at it, one of the team is getting to know how everyone's stuff fits together and how everyone else works, as well as improving overall productivity and raising team morale.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
One of my favourite books is "Pitfalls of Object-Oriented Programming" which was similarly slammed in its day for being anti-object, etc. In truth, it was very much in favour of Object-Oriented programming, and presented ways you can make your life difficult, and how to avoid those ways.
It's always good to have a thoughtful re-examination even of one's most dear religious views. We often don't see the rat-traps into which our minds wander as we enthusiastically accept a doctrine. I haven't read the book, but plan to, and hopefully it will show me ways to improve what is good about XP, and reduce what is not so good about it.
I remember, to provide a historical note again, this same stupid argument happening with the Various modeling gurus. The arguments were mostly religious and stylistic/aesthetic in nature. What always made sense is to take the recipies, practice them, and adjust to your local ingredients.
i.
i - This sig provided by
XP does not suggest coding without considering design.
You obviously don't know anything about XP. Take a look.
A programmer is a machine for converting coffee into code.
Maybe XP is a great tool. And maybe go-it-alone programmers are great workers. How about, when selecting a methodology, we include the personalities and abilities of the available team members in the problem domain. So, in some cases, XP may be the right way to go. But in others it's only good if you fire some of your most competent people (or at least disclude them from the project). In other cases, the iterative XP process may make the customer too jumpy, regardless of the quality of the end product. I've seen users get a "Alpha" version of an app and whine that menu choice XYZ is always disabled, and consequently to app is useless, even after you told them that XYZ is on the "under construction" list. As the manager who approved the app, you look bad in the eyes of your employees. Unfortunately, not everyone is patient, attentive, trusting and insightful.
Fine, I'll build my own moon base! With blackjack...and hookers...in fact, forget the base! - TripMaster Monkey (862126)
Funny, I'm an extreme INTJ, as well (8,6,9,10 on a 10-scale) & I've had no trouble Pair Programming for the better part of the past two years. And, similarly, most of the coders here are INT[P|J] -types, with a few INFP's thrown in.
But we take breaks -- reading Slashdot, Kuro, GoogleNews, etc. walking outside for [air|smoke] breaks, playing with the puzzles around the office, or just bugging the office staffers, up front. All of this allows us to come back & concentrate on the code at hand.
Stuff that matters: circuitbreakers, vacuum-cleaners coffee makers, calculators generators, matching salt+pepper shakers
Ron Jeffries wrote a good review of this book last month; his review avoids most of the flaws the comments here find in this review.
I've only read one chapter, the one up on the web, but it's quite silly. The author repeatedly describes how one team or another did some dumb stuff and it didn't work; many of these anecdotes are parodic fiction, and obviously so, but some of them are presumably real. Then he explains that that dumb stuff didn't work. The trouble is that a reader with no XP experience might be fooled into thinking that XP advocates doing that dumb stuff.
The trouble with liberals listening to Rush Limbaugh, as one poster suggested, is that Rush makes up a lot of lies and passes them off as truth. (See Al Franken's earlier book for details.) If you don't spend ten minutes investigating facts for every minute you spend listening to Rush, you're likely to come away believing a lot of nonsense. The same problem applies to this book: it's largely fiction, and the line between fiction and reality is unclear.
I've been working on an XP team for a year, and I really like it, but it certainly has its disadvantages. I'm very impressed with the people I'm working with, and I'm really happy with our product. The process we use has almost nothing in common with the processes the book criticizes. Still, sometimes it has its drawbacks, and I think you should definitely be aware of them before you jump into XP. But this book is a good source for information on the drawbacks of doing things XP prohibits, not on the drawbacks of XP. See Questioning Extreme Programming for that. (Briefly, XP requires a small team, significant buy-in and resource commitments from the customer, easy deployment, testing support, and flexible underlying technology.) And, you know, myself, I'd be a lot happier with an ATC system developed with Cleanroom than with XP.
I think it's unfortunate that XP has become so fashionable, because now we have programming fashionistas embracing and pushing it, and any technique or technology they embrace gets badly abused. Just look at Java, XML, and C++!
What turns you all off about pair programming is that it doesn't leave you with time for Slashdot at 1:46 pm on a Tuesday you lazy slacker.
The real productivity from pair programming doesn't come from code review, but from the simple fact that two programmers at one keyboard are more productive writing code than two programmers in two cubicles at two keyboards surfing the web 98% of the time.
Gotta love those "moderators" who automatically mark as Flamebait anything that doesn't agree with their myopic viewpoints...
The author of the book said in response to Ron Jeffries' review:
In my experience, Ron Jeffries is right: XP is about never needing to debug. I've been implementing some of the XP programming practices over the last few years, and the more I moved towards test-first coding, complete unit test coverage, and good automated customer tests, the less debugging I've had to do. For me, marathon debugging sessions are almost a thing of the past; perhaps once a year do I spend more than an hour debugging something, and no more than once a week, at most, do I spend more than fifteen minutes debugging something. I would never go back.
In this respect, at least, the silver bullet has arrived.
cjs
The world's most portable OS: http://www.netbsd.org.
Actually I thought there were different degrees of XP. In moderate XP you get one computer between two developers, in really extreme programming it's one between three and in a small office in Cuppertino there's one company where they only have one machine in the office and everyone else uses an abacus. I think the fundamental principle of limiting developer's access to hardware is a brilliant idea, but then again I'm a tester :-)
Don't look back the lemmings are gaining on you