Slashdot Mirror
Questioning Extreme Programming
In short:
This is bound to a controversial and widely read title -- it is a critical but fair re-examination of all of XP's assumptions and core practices. It provides a much needed comparison of XP with other, less popular, methodologies. Overall, XP emerges favourably, with one serious caveat -- the author concludes that XP is only suitable for a very narrow range of projects, and those that can fulfill all requirements probably stand a significant chance of succeeding using any of the similar methodologies. As with programming languages, there is no silver bullet -- put XP in your methodology toolbox, know when it is appropriate and only use it then.
A couple of interesting specifics:
- The author specifically argues, and I agree, that what the XP literature badly needs is a DSDM 'suitability filter' to advise project leaders as to whether XP is for them.
- In the preface, Kent Beck describes the On-Site Customer role as a team, and not an individual role.
This is the 8th title in The Extreme Programming (XP) Series from Addison-Wesley, surely the most widely read series on a software methodology ever! (If that isn't achievement enough, XP also made testing sexy again. I hear that accountancy firms are looking for Kent Beck to do Public Relations work ...) For those of you who have been living under a rock for the past couple of years the previous titles are:
- Extreme Programming Explained (Beck)
- Planning Extreme Programming (Beck & Fowler)
- Extreme Programming Installed (Jeffries et al)
- Extreme Programming Examined (Succi & Marchesi)
- Extreme Programming in Practice (Newkirk & Martin)
- Extreme Programming Explored (Wake)
- Extreme Programming Applied (Auer & Miller)
This new addition to the XP library feature a foreword by Kent Beck. This is important as many of the reactionary XP fan-club will not like this book -- it challenges XP, and I am delighted to see this title as part of the series. Beck admits he doesn't agree with McBreen's conclusions, but asks you to read the book and decide for yourself, conceding that the arguments are fair and reasoned. I come from a scientific background and distrust anything except wide open debate, a position many who welcome XP will surely agree with. A book challenging XP can only help persuade people to give it a go, by addressing their fears and explaining how to manage any real risk.
Check your sourcesPete McBreen is the author of the excellent Software Craftmanship: The new imperative, a 2002 title from Addison-Wesley. In it he outlines an alternative to the software factory model behind much of traditional software engineering thinking. He proposes a collaborative model with small teams, where the software coder is seen as a craftsman in constant dialogue with the customer. Sound familiar? It should, this is a cross between a methodology and book of advice for career programmers, and fits squarely within the values proposed by the Agile Alliance, and arguably popularised most by XP.
I highly recommend Software Craftmanship, and can think of few authors who are as well positioned to give an analysis of XP as it currently stands.
What is the book about?Questioning Extreme Programming does just that -- it's the first title in the series to take a skeptical look at the rise of this popular methodology and question some of the key assumptions. Arguably there was material like this buried in Extreme Programming Examined, but it suffered from a fragmented, detailed view, due to it being a bound set of conference papers.
The author tackles XP in a fair way -- he's extremely excited by the methodology, and it's clearly in accord with his own preferred approach. What he does is tackle each of the XP tenets in turn, questioning their validity, and then moves on the compare XP to other Agile methodologies and asks how XP stacks up against the competition. He also has a look at the common mis-conceptions (from both sides) about XP, and tackles the key arguments against its adoption in the same way.
Let's have a look at the contents to give you an idea of the structure:
- Introduction.
XP: Hype or HyperProductive? - What is a methodology?
- What do methodologies optimise?
- What are XP projects scared of?
- What do other methodologies consider important?
- What is important for your projects?
- Questioning the Core XP Practices
- Planning incremental development
- Truly incremental development
- Are we done yet?
- Working at this intensity is hard
- Is that all there is to XP?
- Questioning XP concepts
- The source code is the design
- Test first development
- Large-scale XP
- Is the cost of change really low?
- Setting the dials on ten
- Requirements: Documentation or a conversation?
- Is oral documentation enough?
- Playing to win?
- Understanding the XP community
- ReallyStrangeSayings
- Feel the hostility; experience the joy
- Transitioning away from XP
- Your choice
- Is XP for you?
- Do you have a suitable first project?
The whole thing. Let's start with the basics, the high standards of the XP series are maintained, with flawless editing and layout. Moving on, the author's position is admirably neutral -- he is knowledgeable about the field, and although he wants to be converted, he argues only from first principles, and only from the evidence. Similarly, at no point did I think he set up a straw man, or tackled the opposing issues in a different manner. I particularly admired the way he avoided polarising issues -- "All models are lies." -- dismissing them as unhelpful in his current investigation. (He points out that much of the fire in the XP debate has resulted from the use of deliberately polarised opinions as a unambiguous goad to further debate within the XP community. Fine within the gang, inflammatory outside.)
The structuring of the book is of particular interest -- the argument could easily sprawl, but is restrained into very short sub-sections, with each section sporting a clear list of summary bullets. As much as is practical, each challenge to a tenet or practice of XP is discussed independently. (This comes across as simple and straight-forward and you may wonder why I even mention it, but I think it's a fine piece of editing and worthy of praise.)
The sections of the book that I enjoyed most were those dealing with the SmallTalk culture that XP grew out of -- he presents an interesting analysis of why XP works within that environment but discusses how that environment is NOT typical of most development. I have some bias here due to my own experience, see below, but had to agree strongly with his contention that XP is weakest when it comes to team resourcing, and the on-site customer. In particular, he argues that while XP restores dignity and human rights to the programming team, it does so at the expense of the poor frazzled customer. Similarly, he argues that the pre-conditions for XP, in terms of the programming staff, are so high that almost any methodology could be made to succeed with that team.
Don't get the impression that this is a negative work -- it's not. Most of XP emerges intact, and I felt that the author genuinely wanted only to restrain people from adopting XP in inappropriate situations -- not to persuade people to avoid XP. In doing so, he actually protects XP from bad press due to teams failing when trying to adopt XP, them blaming XP itself, rather than their own inappropriate circumstances.
What's bad?Er, not much. He sort of pulls in some material re Open Source early on, but fails to particularly build on that comparison, moving instead to a comparison of Agile methods in closed source circumstances. This is a feeble objection -- but really, it's all I've got this time!
Anything to declare?I should probably give a quick sketch of my background before I finish as I am slightly biased -- most of my work has been in the telecommunications sector, where I either worked with a large code-base (legacy) or a large, distributed team (new development). In no way was I working in the XP style, although I became test-infected easily I found it difficult to even imagine how to apply some of the XP practices to my workplace.
XP changed the way I code and work, for the better, but in a large environment, with no contracting customer, and few experts on a complex domain involving simultaneous hardware development I couldn't see any way to do XP. I'm not saying what we did was good, I'll be the first to admit it was broken (hmm, and I'm unemployed now, time to go and think about cause and effect!). The key assumptions of pure XP just didn't fit the industry I've seen most of. (To be fair, McBreen would have called these projects "systems engineering" and placed them outside of the discussion.) Now that I'm seeking employment again, I'm a lot more aware of methodologies and am much keener to work within an Agile framework, as I believe that all of the methodologies, XP included, offer a much better way of developing software. However, the key point remains -- XP cannot be applied everywhere.
Lastly, I should make it clear that I received a review copy of this title from the publisher and did not pay for it. I paid for my own copy of Software Craftsmanship.
You can purchase Questioning Extreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
. Overall, XP emerges favourably, with one serious caveat -- the author concludes that XP is only suitable for a very narrow range of projects, and those that can fulfill all requirements probably stand a significant chance of succeeding using any of the similar methodologies.
Strange definition of 'favourable', that. Not an attempt at a troll, but the rest of the review didn't tell me how XP emerged favourably either.
But in all seriousness, and at the risk of sounding incredibly arrogant, I've not met someone who can keep up with me when writing code. And really, that's not the time for 2 heads, the time for having multiple people looking at a problem is in the design phase - not the implementation.
Code Reviews are great, but personally I hate XP.
As all slashdotters know, computer geeks can be atheists and religious zealots at the same time.
Xtreme Programming is one of the hot buttons (as is Unix, Java, Linux, OSX, etc. - the only common religion here seems to be the hatred for MicroSatan).
Xtreme Programming has a lot of interesting elements (the only one I'm not keen on is the Pair Programming). But, as with anything, if it doesn't work for you, there's probably something similar else you can try - SCRUM, et al.
The title is provocative enough (at least it isn't inflammatory) that XP fanatics will probably find ways to evangelize their methodology and sell it to anybody who will listen. The book does sound like a good read, because everyone needs a strong dose of perspective now and then.
I do bioinformatics programming. The people I work with are biologists (so am I, actually, but I also have a degree in CS.) They don't have CS degrees, but are pretty computer savvy.
However, when I say, "we should apply the extreme programming methodolgies,"
they say,
"coding to the max!" or
"what does this have to do with snowboarding?" or
"the mountain dew commercial was not funny."
and so forth. They think I'm joking and it is impossible to convince them that Extreme Programming is not either a) a joke or b) marketspeak gibberish crap.
Now, b) may be true. However, as long as the method is called "programming.... to the extreme!" it becomes difficult to convince people on the intellectually snobbish periphery of CS that it has even potential merit.
The good and new comes from no quarter where it is looked for, and is always something different from what is expected.
Nothing beats a well orchestrated and well executed plan - i.e., a written and documented plan. If software specifications are not worth formalizing on paper - it isn't worth creating. You can keep your extreme voodoo. It just formalizes the lazy practices of programmers. 50% to 90% of software projects fail because of embracing fly-by-night "technologies" like this. I thought Extreme Programming was buried for good with the dot bomb implosion.
I read the whole article trying to figure out what he was on about. eXtreme Programming? Can anyone give a definition of it? What exactly is it that XP is, and why does this book challenge it? How did XP change the way he codes and works? What is this "popular methodology?" Because that's what I'm most interested in. The author of the above book review assumes everyone has read the book, or knows all about XP.
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.
By the way, what SEI CMM level _is_ Microsoft at?
I'll summarize the book ( without reading it ) :
For extreme programming to work out, you and your team need to have outstanding ability.
XP(extreme programming) is great, but add into it a shaky designer, a loner in the team, or a delusionned (sp?) manager, and the whole thing will crash down in flames. In traditionnal methodology, the problem would rather settle with a non-optimal development process. With XP, you either fly high or crash badly.
The fact that it is a great development model and the fact that it will not work in most places are not incompatible.
But that's just my experience. Take it with a few tons of NaCl.
J.
This is (possibly, arguably) +1 funny, or (possibly, arguably) -1 troll, but certainly not in any way worthy of "interesting".
"new languages like Smalltalk"?
"stop using Object Oriented techniques and move to XP"?
"revenue stream increase of the order of Olog(n)"?
Whoever modded this interesting should be ashamed of themselves: it's not like those gibberish-flags are subtle...
Just remember that TFD is a Design method, and really has nothing to do with testing as in testing the requirements. So it will check that you coded what you designed. Whether that has anything to do with what the customer wanted is another matter.
Which should be checked by the functional testing, but that's written by the customer. And most customers don't know what they want...
M.
And can I live there too?!?!
;)
If software specifications are not worth formalizing on paper - it isn't worth creating. You can keep your extreme voodoo. It just formalizes the lazy practices of programmers
I'm guessing that you must be self employed or in academia, as it is the domain of management to demand complex solutions to improperly spec'd problems and, oh yeah, we wanted it yesterday. I see this happen all the time where they want a rundown of what are the risks of re-baselining the hardware of our legacy system, and can we get that by Close Of Business today? Oh yeah, and these are the same people who say "BTW, try to follow our Business Practice Process if you can, never mind that we completely violated it already"
Oh yeah, we are a fortune 100 company.
And guess what? I don't gamble. I don't drive too fast, nor sky dive. I don't need drugs to get high. I get my kicks by trying to meet unrealistic deadlines. I love death marches... its the only way to know I'm alive
P.S. XProgramming fits right into this real world model.
In the future, I would want to not be isolated from my friends in the Space Station.
The main advantage to productivity is that it is unlikely both programmers will share the same opinion about how to waste one's time. Both will feel guilty about wasting the other's time so neither will screw around as much. Slashdot's effect will wane.
0xfeedface
Extreme Programming seems to be another step in the disturbing trend of turning coders or engineers into robot-computers. Under XP, if you have to fire one of your robots, there'll be more people who can understand what Fired Robot X did, because he never coded anything alone. It also tends to suck the "guru" right out of coding. Consider if you had a pack of middle-of-the-road coders, and one guru. Under extreme programming, the guru becomes a loner, and a drag to the team (note how there aren't actually any individuals, just people to "make code"). Since a pair of fools are better than one guru under extreme programming, you can fire the guru.
The bottom line is not to mistake a business model for a work model, and to avoid anything that mixes business with design.
Maybe you should point out to them that many of the Agile Process folks are fond of saying, "Good Process is no substitute for Good People."
Just because it works, doesn't mean it isn't broken.
Pair programming [amazon.com] is not Extreme Programming [amazon.com]. Perhaps XP cannot be done without pair programming (or perhaps it can); certainly pair programming can be done without XP. Some people have been doing it for decades. (I have, too, in a non-XP context.)
Just because Amazon sells two books with different titles does not mean that they are not about the same thing. Pair programming is one of the RULES of extreme programming, but in my opinion it is the only thing that makes it distinct from any discussion of an ideal customer to production cycle.
0xfeedface
Designing for the next iteration -- not the entire system... In some cases for designs to be useful, the developer must code a portion of it as a prototype to demonstrate that their idea will work and is effecient... If someone says that they can forsee all implementation issues at design time, they are either lying or spending too much time designing :) ... This just can't be done enough... I think that any methodology that calls this to the attention of the development team / project managers is a "good thing".
Regular communication with the end user / customer
On the other hand, some things are not so good/realistic... The biggest thing being pairs programming ... I'm not aware of any organization that is actually doing this... Forget about working from home, putting in long hours, etc if you start using this technique... I'd be curious to hear about organizations doing this, with success...
Finally, I agree that change in requirements is inevitable, but I think that it has to be properly managed... You can't keep getting new and potentially radically different requirements from the client every two weeks, without seriously burning out the development team... and you can't tell me that requirement changes don't affect costs... Like everything in a project, changes must be managed and negotiated... The development team can work hard to implement software, but can't bend time and space to do so...
My 2 cents... And yes, I definitely practice what I preach :)
Chris
Platform independent bug tracking software
Nobody gives you a good estimate on traffic density, wind effects, or load, tells you how you're actually supposed to be designing your supports, or gives any kind of a clue what styles or decorations they want. And then a year later they'll say traffic density has doubled and they want two more lanes.
Don't be so presumptious that programming is some mystical black art that can't follow any rules. Every lengthy process benefits from planning and analysis. Just jumping in and working only makes you take longer to finish, cost more to build, and the final product doesn't perform as well.
you really Kontradict yourself there. you state that XP makes better code and in less time, but you don't like working with other people "directly". then you say, well my code doesn't have that many bugs.
/., but are you really missing much? to me the day is much more fulfilling...
in my experience, people who don't work well directly with other people work on software maintenance, not software development. that's where it's easier to not product bugs because there's hopefully slews of regression test suites left over from the guys who put it together.
i'll admit that working on a team project with lots of people doesn't leave much time for reading
one key thing that i've noticed that is missing lately, and the reviewer mentioned it, is team leadership. team leaders have started jumping on this project management kick, and there's really no leadership for the teams. everyone wants to manage, manage, manage. i'm of the thought that a little leadership and the project will manage itself (though the teamwork).
The only people that write about ideal methodologies and their theoretical applications are academics. I am reluctant to use the term "scholar" on these people.
The key to a successful project is design. Even OSS projects have a design. Anybody can attempt to write for the project but if it doesn't fit with the design or is too far off base to incorporate into the design, that code doesn't get into the next release.
Extreme programming is a ridiculous term. Perhaps a better description is "ad hoc" programming.
Think about evolution itself and you'll see how much damage ad hoc programming can cause. :)
Laws are for people with no friends.
XP entirely consists of about 20 helpful programming tips:
...and so on. These helpful pointers are treated as if they were the ripest wisdom, but actually they're just common sense. They're obvious to anyone who isn't retarded. The few things in XP that are controversial (like pair programming) don't work.
"write unit tests first."
"leave optimization 'till last."
"develop iteratively."
The importance of XP is exaggerated to an incredible extent. I've heard more than one person compare XP to OO! Consider the vast amount of thinking of research that went into the development of OO. XP is comparable in importance to a "Frequently Asked Questions" file for beginning programmers.
I've had very good results with XP-ish techniques. On some projects I use just a handful of the XP practices; on others, nearly 100% of them. I've used all of the practices enough to understand them, and have found that the XP community has an unusual concentration of effective, smart people.
Yet I have little interest in XP-sucks-XP-rocks flamewars. In fact, because of the good results I've had, I'd really much prefer if my competitors decide that XP is a terrible idea, pair programming is insane, writing tests first is totally backwards, integrating every few weeks is plenty often, and changing requirements are a nightmare. It would suit me just fine if my competitors reject XP completely.
So please, if you're curious about XP, forget about it. There's nothing to see here, please move along.
Why does this post get mod'ed as Funny? And everyone replies to the question with a joke? Apparently, I have been living under a rock because I for one haven't heard of XP and I'm in the 5th year of a comp sci PhD. Have I acquired an immunity to software engineering flavors of the month?
So long, and thanks for all the Phish
My team tried out Extreme Programming/Pair Programming (yes, I know there is a different and I guess ours was more Pair then Extreme but anyways) and we had mixed results.
The best team was when one of the programmers was very good at design, documentation and managing how the pieces fit together while the other programmer was good at the 'bits'. Coding an individual section based on what the first programmer told him. That team worked wonderful and churned out alot of work because thier strengths were complimentary.
However, another team just had to programmers who sucked at managing the process, design and documentation and both just tended to write out code. This led to conflict both in how the code worked (each coded a section without thinking how it would work with the other section) and between the two programmers.
We are back to individual programming now, just with freqent code reviews. Also we love to go through CVS checking for bad habits and bash whoever did it (Sucks when you point out a issue and then realize you are responsible for it though).
Summary: I think it all depends on the type of programmers and what they are good at on if any methodology works.
Remember the good old days before coding and climbing were 'extreme'... Its seems as though the XP methodology ignores the common sense approach that a small group of motivated talented people with a bit of leadership is what you need, no amount methodology replaces these things. I don't think people who are really good developers can work in the environment XP requires, its to limited and suffocating. Maybe some day management will understand that the secret to good code is people, and not just the latest fad in methodology. MM
Did you ever wonder why every commercial aircraft of a certain size has a captain AND a co pilot?
Because the co pilot might realize an error or a danger the pilot did not realize.
And missing an error in the plane is a tad bit more important than in a program. And it's not like if the copilot could go fly -another- plane instead of co-piloting that the airline would get any benefit. They don't get more money for being able to fly more planes.
How many compiler errors do you usaly correct after a compiler run? How long does it take to get 10 lines changed/eddited/added and compiled successfull?
Far, far less than 50% of my time. For each hour I spend coding, only a few minutes will be spent fixing compiler errors.
Anything less than 50% means that XP is a loss, not a gain.
A pair creating 100 lines of code distributed via 3 classes in one day and getting it into production another day or having to single programmers coding 200 lines of code where 50 lines from each one are similar to the other ones code resembling the same concepts expressed by different people?
Forget that lines of code are a horrible method of measuring productivity, and the slanting assumption that 1/2 of each programmers work would be redundant. Actually, don't forget that. If you can't divide work in such a way that your programmers aren't doing more than half non-redundant work, you have problems XP won't solve.
But anyway -- the question is which is more efficient. While I believe that with XP the two-person programming unit is more efficient than a single-person unit, that isn't enough. If the increase in efficiency isn't more than 100%, then you would be better off having the programmers work separately.
Please stop bashing something you have not at least used/applied for a couple of years, and don't call yourself an expert if you have not used it at least for 10 years.
I have a new programming method. I call it Jabbing a Stick into Your Eye. Don't knock it until you've tried it for a few years.
Thank God the rest of us can recognize a bad idea without doing it for years first.
The enemies of Democracy are
I don't think that's a useful comparison. Aviation is quite different from programming. In particular,
So there are more reasons for having two pilots than your simple explanation suggests. Not too long ago, an engineer in addition to the two pilots was standard in commercial jet liners. Perhaps we should introduce triple programming, with one person doing all the typing and the others the actual programming?
Also don't overestimate the gain of having more than one person involved for safety. There are countless reports of social problems within the flight crew contributing to fatal accidents. Some captains do not listen to their co-pilots, some co-pilots don't dare speaking up against their caiptain even if the captain is wrong, and even a crew of three might forget to check the altimeter while trying to investigate a problem with the landing gear. Not to mention communication problems between crew members, distraction by crew members, etc.
http://erichsieht.wordpress.com/category/english/
We used to do this in college all the time. Someone would get stuck on a problem and suddenly there would be 2 or 3 other people trying to help. The same at work: Someone stares at a problem for so long they need a second set of eyes to double check some piece of code. We did not have a name for this but I suppose we could have called it "Ganging up on a problem before going out for a beer".
And missing an error in the plane is a tad bit more important than in a program.
WRONG!
You have no way of knowing what other people are programming, but buddy, if you miss some types of errors in some types of programs, Bad Things Happen. Many of the moving things in the world are fly-(or drive-) by-wire - what do you think is figuring out "for this input, do that output"? A program.
Quick example - the first Ariane 5 blew up due to untested software and hardware reuse - they took a piece of equipment that worked fine on the Ariane 4 series, stuck it on the 5, and didn't test it throught the full flight envelope - but a software design decision that worked on the A4 (not to bounds-check certain values) was invalid on the A5 (you COULD get that many bits of the values on that rocket) and when it happened, the software said "It's gotta be bad hardware! Turn it off!" and swapped to the redundant module - which was busy locking up with the same error. Boom.
Now look at the millions of lines of software in the Boeing 777. The microcontroller in your grandmother's pacemaker. The computer-controlled milling machine that shapes the turbine blades of jet engines.
And it's not like if the copilot could go fly -another- plane instead of co-piloting that the airline would get any benefit. They don't get more money for being able to fly more planes.
No, he'd get laid off. That's economics. Airlines don't want spare bodies getting paid salaries - if they could train chimps to fly, and the FAA would approve, they'd do that.
Lines of code may be a horrible way to measure productivity, but it's very hard to get accountants to believe in "function points".
I agree that XP isn't as efficient as "normal" programming when both programmers are experienced - what I've seen work in practice is the use of XP (adapted slightly) as a training ground, where inexperienced personnel are combined with experienced personnel to cross-train. It works both ways - you can have a wily old Unix coder sentenced to work on MFC sitting next to a kid who's only done Visual Basic, and both will learn a lot, and be more productive as a team than either or both separately. It's a matter of chemistry as much as management.
But then, that's just an opinion. It matters little.
I love vegetarians - some of my favorite foods are vegetarians.
The less skilled of a pair should usually be driving. That way they have to understand their partner's suggestions (instead of letting their eyes glaze over while watching them appear) and they'll become more skilled. Look at it as a training cost. If they can't or don't want to learn and improve, software is not the field for them.
1) This is evidence that the developers you work with are "small" people. People with over-developed egos shouldn't be hired into an XP environment
;)
2) If brittle features are being produced, then the coding is poor. It's my belief that short cycles are more likely to produce better code, given a decent coder.
3) I think this needs to be taken with a grain of salt. It's not the absolute simplest thing that can work that should be done, but the simplest thing that makes sense that should be done. A co-worker of mine has a sticky note that says "don't copy broken code". That might be ammended to read "don't write crap code". also see me response to #4
3b) If the developer is tweaking a test just to co home, they need a swift kick in the ass. see the recommendation not to write crap code above
4) This is what re-factoring is for. As soon as you have repeated code in a few places, it's time to site down, actually think, and refactor the code to remove the duplications.
It very much sounds to me like the problems you've had with XP are not problems with XP itself per se, but problems writing decent code in general. XP is not a magical want that will make everyone's code beautiful, efficient, and flawless, but it does provide a framework in which high quality software can be produced and maintained relatively efficiently and painlessly. My experience with it has been extremely positive - maybe I'm biased
Don't feel bad. You're not the only one-- probably less than %1 of the slashdot crowd has heard of extreme programming. After all, perl hackers and other non-programmers have no need for it.
Slashdot is not a technology or programming site-- it is a linux fan site. Unfortunately, a surprisingly small number of linux fans are programmers.
If you do decide to start programming (And that kid who's in his 5th year of CS had better get up to speed!) then XP is something very much worth learning, even if you put none of it into practice.
Yeah, and you guys panned the ipod too: http://apple.slashdot.org/article.pl?sid=01/10/23
... is that it is tied to Smalltalk, and hence to object-oriented methodology.
OO isn't the only way to program. It isn't even the best way to program, in certain situations.
XP, Design Patterns, and fads like these are all nice in that they reflect certain practices which make for good software. But they are the CS equivalent of "How to Draw Comics the Marvel Way": great at what they do, good at expressing the concepts behind a particular style/method, not very useful when you want to cross over into other styles/methods.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Really though...all else being equal, is it better to have a company full of developers who can cooperate, or a company full of developers who can't? You've got to be a goddamn moron to pick the former.
As for the design part of things...this is just my experience successfully using XP for real business software development: Do you need design? Yes. Do you formal design? No. Do you need to design everything ahead of time? Absolutely not. XP came about in part because enough people found that BigDesignUpFront just doesn't work well enough.
As for my tone...this is some of the nicer stuff I post on Slashdot. Karma to burn.
pooptruck
... to 1976. Remember PSL/PSA? RSL/RSA? All their brethren and siblings? Probably not -- many of you hadn't yet achieved zygote status at that point.
Anyway, the same breathless hysteria about how processes improved, productivity increased, errors decreased, etc. etc. blah blah blah was rampant back then. I was a (very) junior member of a non-profit team hired by the Army to figure out whether these claims were true or false.
Our conclusions were simple. The productivity and other claims were hopelessly inflated. However, we were able to conclude that any systematic methodology seemed to produce somewhat better results than no methodology at all -- and it didn't really matter what the methodology was.
Deja vu all over again.