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.
I'm not a big fan of the ESPN Extreme Programming. I much prefer things like ESPN Classic or SportsCenter.
OK, I'll take the fall here: am I the only one out there who's never heard of eXtreme Programming? Judging from the name, it sounds like hacking code on a laptop, nude in the snow. WTF?
Just like Clinton.
I personally prefer to be on my own. I could see how managers prefer it because it forces more work to be done and yeah, it prevents a lot of errors, from my experience.
But I hate it - I hate working right with someone else.
I personally would rather to just be near someone and ask them questions about code if need be, but I hate the XP experience personally.
There are some odd things afoot now, in the Villa Straylight.
Hey, a like XP ... i use it, it brings results to me.
The time that is used up when the better programmer is slowed down does not get repaid through gains in productivity of the pair. The slower programmer will simply drag the programming pair down.
Even pairing two good programmers results in no gain in productivity. While they are wasting time coordinating with each other, they could be separately making large programming progress.
The collaborative process is inherently worse than the distributed process. Look at the quality of Windows vs. Linux. Windows is developed collaboratively with meetings and close contact among the programmers. Linux is developed in a distributed process where anyone with a clue can make significant contributions to the project. One is a steaming pile of horse shit. The other is a robust, stable solution for the computer space.
. 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.
One is a steaming pile of horse shit. The other is a robust, stable solution for the computer space.
It's unclear from your post as to which is which?
Allright, the book is good. But it would have been nice to say in the review what XP is. Maybe most people on Slashdot know, but _I_ don t ...
My consulting business was struggling with trying to manage the overhead and maintain current on all the new methodologies and languages that come out like Smalltalk, and C# and we were having trouble meeting those demands. Then I made the company-wide decision to stop using Object Oriented techniques and move to 100% Extreme Programming methodologies. The results have been astounding.
We've seen our revenue stream increase on the order of Olog(n) and we with the word of mouth advertising we are actually turning away customers in an depressed economy where legacy shoftware shops are going out of business.
I know on slashdot there are many people who like to deal with theories but that's a real world tesromonial to XP.
Warmest regards,
--Jack
Wagner LLC Consulting Co. - Getting it right the first time
Close, but not quite there. Your code is not extreme code, it's shite code - you are being a shite programmer.
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.
My company had a lot of lazy/stupid people hired under quotas, nepotism, or because, in the case of one person I worked directly with, it was the "Christian" thing to do.
Management attempted to impose XP to keep these lunkheads busy, but it was a disaster. To quote Butthead, You can't polish a turd.
XP is many things, but it is NOT a solution for serious mistakes made by HR.
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.
is the price! These are slim volumes (186 pages in the book under discussion, 265 in my Extreme Programming Installed) but they carry a hefty price tag.
I end up buying only one or two, because I can't justify the cost (to myself or my company) of the whole series when I haven't made a commitment yet.
Also, what kind of overlap is there in the books? I looked through the XP For Web Programming sample pages at Amazon, and it looked like the same content as my book.
Initially we took an old project and applied Unit testing to it, which really turned us off the concept. But once we started a new project, and wrote the test cases before our code it suddenly made sense!
Now its instinctive for us to write the test cases first, It also allows cuts down on refactoring later as all our code is at its simplest level always. If our code is changed in the future, any problems will be identified straight away.
I'm sure in the future we'll attempt the other concepts behind XP
It's hard enough to remember my opinions, never mind the reasons for them..
XP has an active and interesting mailing list.
More information about XP can be found here or here.
Check this out.
Mother is the best bet and don't let Satan draw you too fast.
I agree with this post. ;-)
Hi "girls".
Not to be pedantic, but Smalltalk has been around since about 1980...that hardly qualifies as "new" these days.
It is a good idea (for somebody) to experiment with software engineering ideas. I have no problem with that. However, these conditions should be met:
1. Test it on willing and knowing *volunteers* only.
2. Don't claim it is "better" until it has been road-tested for a while. At least 3 years and preferrably 15.
3. Identify where it works and where it does not, or at least be clear about the domains and situations and scope about where it does work so far.
There are too many credit-cravers and talking heads out there pushing buzzwords into the mainstream before they are tested properly. They should take some clues from the medicine industry. Sloppy pushing may not (directly) kill people, but it can certainly kill the economy and IT credibility, as we have already seen.
Table-ized A.I.
If that isn't achievement enough, XP also made testing sexy again.
Erhm, no, it didn't. Nothing's sexy about XP. IMHO, XP took much of the fun out of programming. The chaos that is open source development brought it back.
People seem to think that pretending programming is always as complicated as particle physics is going to somehow produce better code on time. I don't. Sometimes coding 9-5 in pairs and creating ten AbstractFactoryContainerXYZYourMom objects each time there's a need for a one line getter method just isn't the way to do it. It might be necessary when working on safety critical systems, but I doubt even that, as formal methods is probably what will dominate in those cases anyway, and for your average off the mill app there's just no need. But, as I've already said, what's worse is that it's no fun.
And don't give me that "statistics has proven XP is not only more reliable, but also much faster"-bullshit. I've seen it in action. It just ain't true.
"If you think education is expensive, try ignorance" - Derek Bok
Best coder? Where do you work, a mayor's office in Kansas?
Come to Manhattan, NYC, little girl, and we'll see if you can still hang.
Thank god you said that - I was really worried all these trigger happy mods were just going to mod that thing into hell. You stepped in and averted a disaster. Great work.
Hahaha, nice one.
The funniest thing is that mods took you seriously: you got moderated 'insightful' and 'interesting'. I'd say you'd deserve 'funny' or 'troll', but eh...
You have trolled, you have won, have a nice day!
A message from the system administrator: 'I've upped my priority. Now up yours.'
that you no longer need your corporate site to work?
Cool.
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...
Stupid job ads, weird spam, occasional insight at
xbox, XP, Xtreme Programming.
Windows is appropriating the X, what once generally stood in for Linux things.
Very sly, and no one notices.
We used these four concepts and since the code we put out was so much better than anything our clients had ever paid for, we had more work than we knew what to do with. It was incredible.
Oh-and Boss, take the guys out for a beer at lunchtime every once in a while, and encourage a 5 minute break every hour or so. A happy coder is a good coder.
They'd point towards "the planning game," the XP deliverable for project management. (See Planning Extreme Programming for details.)
They'd point towards "user stories" (very similar to use cases), one XP deliverable for requirements gathering.
They'd also point to projects where the requirements weren't well defined up front and changed very quickly, and the cost of maintaining detailed requirements deliverables would have slowed the project down enormously.
And what project doesn't fall in that category? It's a fantasy to think, ala classic "waterfall" development, that the requirements can be set in stone before any of the design, coding, and testing is done. Requirements grow and change as the project progresses, in ways peculiar to the "softness" of software development. (No one would start a project to build a footbridge over a creek, then halfway through want a rail bridge over the Mississippi River.)
XP may not be the best way to address this, but it's one way; and even as McBreen concludes, it's a good way for some projects. For all projects? No one's saying it is.
Stupid job ads, weird spam, occasional insight at
A plan is nice, until the customer changes her mind. Then you're fucked unless you can change your software, too. XP is a series of techniques that make software development flexible enough that you can keep up with the client.
For example: write your tests first, then write code to pass the test. That ensures 2 things: 1) you always have tests for your software and 2) see #1. Need to change something? Go for it, you already have a test that will tell you if your change is ok. Maybe that's not important for a 2-bit consulting shop, but it's sure as hell important for any real enterprise.
Another technique, pair programming, catches a lot of flack for being slow, blah blah blah. It's not right for everyone, but it works for a big portion of the population. Not everyone is a good programmer, and even the good ones do stupid shit. Having someone watch what you're doing works. The advantages aren't as pronounced when using a really good IDE, but they're still there at the algorithm level. Consider it a realtime code review.
XP is also great for those pesky marketroids who always need a demo that's different than the one they did for the last trade show. XP preaches continuous integration, which means that your software is always at a stage where it runs. That's a huge fucking deal on any kind of real project.
You're welcome to your own opinions, of course, but don't be upset when you're out of a job because someone else (like me, ha) has a shop that can meet the customers' demands in half the time with twice the quality.
See subject
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
If we can't be properly crude, at least be crude properly.
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.
Mention O(log n) in your troll and the mods go wild!
Finally, I have met someone who likes saying goblin as much as I do! Yay! Goblin! Goblin! Goblin!
Republicans are too busy screwing all the other voters.
The only acceptable sport / hobby / whatever for which such a prefix can be done justice: Extreme Ironing.
No, it's not. It's really very structured. The simple definition given above is one of the main reason XP-projects fail.
Basically XP is a bunch (11 or 12?) of well known best practises taken all the way out (if code review is good, then more code review is better, so let's code review all the time).
It's heavilly based on communication, so it will break down with large teams. It's also missing an architecture step, so large projects tends to fail, if you don't "cheat". And it's missing testing. But if the product is rather small, the people on the team communicate well, and your QA-team gets a go at the app occasionally, you'll be doing great.
Probably the best thing about XP is that it brings back the fun in programming. Writing out-of-date documents isn't any fun.
M.
it was made at xerox's palo alto research center in in 1972
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
What are the basic mechanics? Usually, one programmer is typing and thinking out loud about what needs to be done. The other sits and offers suggestions. Sometimes, the keyboard changes hands.
The first few times are not typical. You will spend time discovering tricks with editors and discussing personal work habits. You will find it exhausting, and neither will be unable to type for more than half a day each. Remember to pass the keyboard back and forth, and keep your paired days short.
After the novelty has worn off, you find that every partner is different. Nevertheless, the benefits seem not to depend very much on whom you work with.
What is one guaranteed benefit? All code written by two people is at least understandable to two people. Two people can maintain it, so others are more likely the find the code maintainable as well. Upgrades and bug fixing will always consume more of your time than the negligible first draft of a program. If your code can't be maintained, then you really cannot afford to ship it, no matter how useful the functionality.
Better, the two of you are thinking about the code in different ways. While the typer is thinking about one screenful of code, the companion is thinking about the effects on other code. Maybe this bit of functionality belongs elsewhere. Maybe this information can be encapsulated. Maybe we're making a bad assumption here. You catch many opportunities to simplify your code and improve flexibility.
It's hard to think about the big picture and the details at exactly the same moment. While you're thinking about one, you mess up the other. With twice the brain capacity, one of you can focus on the details, while the other checks the context and adjusts priorities.
I also find that we get more than twice the work done of either of us working alone. A speed-up isn't guaranteed, or even necessary, but there are good reasons why it happens.
Much of the time you spend in front of a terminal is wasted by context switching. "OK. Where was I?" You decide something must be fixed or refactored before you can make any progress. You spend twenty minutes making the extra change and you lose the thread. Your original idea goes cold. Or you postpone and never get back to the necessary refactoring. Worse, you may spend an hour restructuring code, then realize it was not necessary after all. There was a simpler way to solve the same problem, or you misunderstood the problem. Two people will stop each other from wasting many hours this way. One or two such insights can justify the entire session.
Pair programming is also constant code review. You get to discuss and and explain the design at the most optimum moment, when it is being written. Alone, you might get ninety-five percent of a design perfect, so that no one could possibly improve on it. But that stupid five percent could have been avoided by almost anyone you pull in from the hallway. You could have avoided it yourself on Tuesday, but today is Thursday, and you were using a different part of your brain. Two people are less likely to have the same blind spots.
Each programmer has a high tolerance for complexity in certain types of code. Certain strange idioms are second nature to you, but to no one else. You won't know for sure, unless someone is sitting next to you asking "What the heck is that?" Then you'll break the one clever line into several readable lines, and move on.
You'll like your work better, others will like your work better, and you'll get more done. That should be enough reason to give pair programming a try. Maybe it won't work for everyone, or everyday. Don't force yourself or others to participate. You must be relaxed and receptive. As with any new skill, it works better with practice. Try with different partners and different problems. If you find yourself staring blankly at the screen, then surely you can't do any worse with someone else in the room. Try it right then.
What if your programmers work in different cities? Try using an instant messenger, such as IRC, Jabber, or Yahoo's. These allow you to pass files and snippets of code back and forth. You can archive your conversations.
(Reality reasserts itself sooner or later.)
Heck, they wasted millions by subpoening the President for having had his dick sucked. More recently the sight of breasts on statues offended Mr. Ashcroft to such an extent that he ordered them covered.
Dirty, dirty, dirty!
Of course, if she's 5'8". 36-24-36, and in her 20's, I might have to change my mind.. :)
36-24-36?
Haha... only if she's 5'3"
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.
I can see where your comming from and I totaly aggree
What happens when the single progammer is sick or leaves, yeh I can see how productivity is going to sky rocket.
How about the cross training that goes on when you have more than one person working on a project, that's useless of course.
Social aspects to working with someone else are a right pain, I wan't to work for a company that sticks me in a hole and leaves me there, that'll get the most out of me, and I'm sure to stay.
"Windows vs. Linux", Ok I'm no windows fan but has anyone noticed all the bickering that goes on in the Linux comunity,
I can see the productivity gains apearing right before my eyes (are there still atleast two VM's kicking around?)
thank God the internet isn't a human right.
Everyone is posting about XP but I would like to address the review.
It was rather thin. I didn't see much insight into the book's ideas or even the writing style. I didn't come away with any sort of idea if I should buy this book or if it would be of use to me.
I like book reviews. I think this was more like a very short book description and summary of the table of contents. Reviews talk about a view and not just a summary.
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.
http://c2.com/cgi/wiki?EmbraceChange
:)
That is something that should be read by all "Waterfall" developers like you. It is very useful, even if you don't change your opinion.
Damn. IHBT.
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.
For a well written case against XP (just 14 pages) follow this link ... Then we embraced XP and we were cured.There was light again. Our project was miraculously(sp?) saved and we were on time. We had a happy customer and esctatic(sp?) developers. Thank you XP"
XP does have a limited value. I like the fact that it promotes early integration, and unit testing (Again they are not XP inventions). The rest of it is snake oil.
Also the guys who promote XP do so with a religious frevour. Most of the so called success stories go along the lines of
"All was darkness, the project was in a mess, the product was delayed, the customer was angry , the developers were tired
Try questioning XP in one of the message boards and you will be greeted with it "Just try XP and you will be enlightened. It's counter intutive and dosen't make sense but it somehow works".
The scariest part is the "code is the documentation" tenet.
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.
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.
I don't understand your comparison between OO techniques and the XP methodology. Seems like apples and oranges to me.
Since the poster changed both methodologies at the same time, it did indeed make it harder to tell whether the key factor was XP or OO (or both). Perhaps he/she should have switched one variable at a time to make it easier to narrow down the culprit/fix.
Indeed, XP and OO are generally considered orthogonal. However, IMO, OOP failings is what *caused* the surge in XP because OO failed to have a *consistency* to it after almost 15 years of mainstream use. I have tried to find "accepted business practices" for OO custom business software designs (my niche), but there seems to be no agreement nor consistency in methodologies published. Most materials focus on device drivers and systems software, not custom biz-ware.
The most glaring lack is knowing how much to model in the database (schema structures) and how much with OO classes, or whether and why to mirror the classes after relational entities, etc. (Mirroring should be avoided IMO. Duplication is generally a software engineering no-no.) RDBMS are here to stay for good or bad. OODBMS are a market failure in the custom biz market for the most part. OO better get used to RDB's and figure out smoother ways to work with them instead of wasting their hope that OODBMS will come back to rescue them from relational-land.
Thus, practicioners have thrown up their hands trying to find "knowable" OO biz structures, and instead looked to more "organic" approaches like XP. XP allegedly removes the burden of having to plan right up front because you grow it by actual customer/user requirements, not by plans.
Procedural/relational (p/r) structures have proven more consistent in my observation. Even bad p/r shops tends to follow a consistent pattern: divide code and projects up by "task", and put the noun model/state into the relational database. This approach *works*, especially if you have people who know what they are doing (good DB designers, industry experience, and the ability to factor out common behavior to shared libraries or code.)
The biggest fragility of this p/r technique is the database design. Bad schemas *will* drag you down over time. Thus, good DB design is paramount under it. If your org is going to allow slop into the system (an unfortunate fact of life sometimes), then make sure it is *not* at the DB-level. This admittedly is probably the Achelees Heel (fragile spot) of the p/r approach if there is one. But, it is relatively easy to prevent.
I personally think experience and planning alleviate the need for XP under good p/r techniques. I have made too many wheels to want to waste time reinventing them over again organically on each XP project. Good p/r that I have seen does *not* have a high rate of failure, which is what motivated XP to begin with.
Perhaps use planning for the parts you are comfortable with, but XP-like techniques under the iffy parts. This may get you the best of both worlds: take advantage of existing knowlegde, but use the organic (XP) approach on the fuzzy spots. Thus, an all-or-nothing attitude toward XP may not be warranted. It is a matter of knowing and admitting your limits and applying XP-like techniques at those limits.
Table-ized A.I.
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
The best technique I find is to use a concurrent versioning system (I HATE the bondage-and-discipline exclusive checkout stuff) and _allow_ programmers to work in pairs if they so wish (this works best for people of approximately equal abilities - if one guy can't stop typing and hand the keyboard to the other guy without any fuss, then they're not suitable for pairing), and with the understanding that they will be told off for too much off-topic discussion, but _require_ that code merges be done in pairs.
That means that single-programmer originality isn't necessarily cramped, but paired-programmer attention to detail and common-sense-checking is applied when merging changes.
Here's another review from the Extreme Programming camp that takes the book to task on several issues.
Ken CauseyI've since moved out of coding, but back in school we used to collaborate (really collaborate -- not copy) frequently on assignments. There was this one guy who invariably dragged the rest of us into these annoying conversations about the stupidest things. Nice guy, good coder, but the best way for me to work with him was to lock him in a separate room, disable talk and msg, and only respond to his emails once per hour.
During our OS course -- our most brutal required course -- I specifically avoided this guy by finding my partner a few months in advance. After working out the design together, my OS partner and I would start off working on separate pieces, but eventually, we'd end up pair-programming. This was incredibly effective for us. With both of us on one computer, we actually wasted LESS time co-ordinating with each other, since we understood each other's pieces better, could integrate code faster, and we made fewer dumb errors because there was always someone to look out for them. While we might do the grunt coding separately, the tricky parts and the nasty debugging always ended up in being completed in a pair.
Mind you, though I couldn't work with the first guy, other people I knew could do so effectively.
The point is that pair programming doesn't work for every pair of people. When you have a good pair, it rocks. When you don't, it bites. You not only have to respect each other's skills, you also have to have complentary working styles and thinking styles. In my pair, I was better at high-level design and creating test cases, while my partner was better at hammering out the implementation details and diagnosing bugs.
If I ever went back to coding, I'd want to do it in pairs -- so long as I could respect my partner.
I can spell. I just can't type.
It is a management tool made to look like a geek toy.
/.) may sound nice to management, but it doesn't make for a nice working environment - in fact I'd say it drives people very quickly to being burned out.
The name attracts geeks: they like 'extreme', they like programming, so XP must be great, right?
Wrong...
In XP, the idea is that two programmers are constantly working together. One of the two types code, the other watches his every move. "Don't forget that semicolon!" "No, don't do it like that!" "You don't need to do that right now!".
Having a slavedriver who puts the whip on you whenever you stare out the window (or browse
Another mantra of XP is "never write anything you do not need right now". As with top-down or bottom-up programming, this tries to force the way a programmer thinks into a narrow pattern.
Personally I've found that I'm at my most productive when I have a good flow going. That may mean writing some support classes first (and completely) and then building something on top, or it may mean going chaotically all over the place adding bits, but it never means doing things precisely in one order.
I've also noticed that it is not possible for two people to sync their 'flows' when they're coding. Yeah, bring forth the lame jokes...
The problem with all software methodologies is that they are usually associated with some software guru who is trying to make big bucks as a consultant selling his brand. Also methodologies very often become religions, with the head guru being the leader of the cult. This is understandeable since most software developers depend on a song and a prayer to get their code to work. XP is a good example of both trends.
I wrote a white paper on software methodology which you can download here. I am an agnostic when it comes to methodologies, but there is alot you can learn from what's out there.
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".
Research XP. Research the alternatives. Use whichever works best.
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
Thanks for the link.
To contend with a few points:
>1. Divide your project into a bunch of moduals
Nope, come up with a set of stories which describe a functionality of the project. Prioritize, estimate, and figure out the smallest useful release possible.
>2. Make teams of 2 programmers and assign each modual.
All code is collectively owned, not assigned. Teams change hourly, daily, or weekly atleast.
MODULES are not planned at the beginning, the simplest code which satisfies a current need is used, and then evolves into a set of objects.
>Program it without worrying too much about how things fit together.
One of the pair is exclusively responsible for "how things fit together."
>3. Fit the moduals together
This is performed atleast twice a day and a thorough list of tests proves it worked. No code is ever committed unless it integrates.
Careful, a little Software Engineering knowledge is just enough to really screw things up.
In the case of structured programming, I wouldn't say that it's come and gone; rather that it has simply been pretty generally adopted, and hence isn't trumpeted or bragged about.
Some IT fads eventually work and some don't. In my observation the success ratio is roughly about 1-in-5. Structured programming (no Goto's) and relational databases seem to have pretty well "stuck". OOP and Client/server are kind of in the same middle-land boat. They seem to work okay in some niches but not others. I remember the tail-end of the CASE craze. Then there was the Expert System craze. In the late 1970's was the "extreme" top-down craze, which was actually the extremist end of "structured". It later mellowed out to being at a routine or module level instead of application-wide. Thus, even good things can be taken too far.
Now we have web-applications, web services, UML, and XML-everywhere fads that are having their try. (Curiously, I just saw part of an article that claimed very UML-like approaches were tried, and failed, in the 1970's IIRC.) Most of these I would not personally bet on lasting in their current form, beyond minor roles. I think B-to-B web applications will be replaced by "remote HTTP-friendly GUI" technology of some sort (like XWT or SCGUI).
Table-ized A.I.
So when do we get taichi programming? Or maybe lagom programming? :-)
If the obvious pointers are as common as you say, why are they so widely unused?
Can you elaborate on how pair programming doesn't work?
(By the way, there are 12 XP features.)
how to invest, a novice's guide
I agree 100% with this!
I was always getting irritated to hell with people in academia who thought that CS was a completely new and unique subject that could not be taught with the same principals.
I do not believe CS is exactly like other fields, but to think that nothing can be learned from them borders on asinine.
Yeah right - everyone knows the most visibly uptight people are the most perverted once the bedroom door closes.
(BTW, Clinton was "[suboenaed] for having his dick sucked" by Paula Jones' attorneys, not by "Senior Republicans").
I'd recommend this article as a well-argued critique of XP: Case Against XP
Just use the acronym. Acronyms always sound professional.
Kudos to Addison-Wesley and Kent Beck for including a book like this in the "official" XP series.
Now, can we expect to see a book called "Perhaps Windows is Not Always the Best Way" being published by Microsoft Press?
The one thing I could never see anyone in upper management buying into (aside from the name Extreme Programming) is the concept of Peer Programming. Allocating two perfectly capable resources to one desk during all development time simply does not seem feasible (not to mention desireable) to me. How many of you true developers out there would like one of your co-workers over your shoulder the entire time you were writing code? Or better yet, how would you like to be relegated to being in the passenger seat and simply observing and offering verbal input to the development process? Not very many of you I'd imagine.
Extreme Programming does have quite a few refreshingly positive aspects to it however:
Come out with small releases and come out with them often. This keeps the customer very involved in the entire development process and goes a long to to ensuring they (a) get what they want out of the system and (b) take on a true partnership role in the project. This is especially helpful, since we all know that specs often will begin to change the minute they're committed to paper anyway.
Full testing of the entire system each time a release comes out. How many times has a small change in one area of the system ended up affecting another in some unexpected way? This concept takes care of that situation as well as gauranteeing comprehensive Q/A in general.
No fear of code refactoring. I love this one, because we all know what a pain in the ass it is to have to completely reengineer some piece of code or process that is in place and working, but is discovered to be unscalable or deficient in some way in regards to future use. Building around it only makes the situation worse though, doesn't it? Don't be afraid, rewrite it and make it right. There's usually no way of knowing everything a specific process may be called on to do from day one anyway.
We all own this code. The concept of all developers being able to work on any piece of the system makes much sense. I used to work in one shop where the brilliant mananger decided everyone would have one area of responsibilty, thus having him make statements to users like "Oh sorry the search engine is not working, but we can't get it fixed till tomorrow since Andy is out today and he is the Search Engine Guy". Everyone being able to change the communal code does require that you have a group of developers who are all competent of course - which is not always the case in the real world.
I guess my take on it is that you simply cannot apply the principals of Extreme Programming as a simple "black-and-white" practice. It's really got to be somewhere in the middle to make it work in the real world ...
- Both XP and Agile advocate self organizing teams. This is most certainly how Open Source works. Corporate development models force developers and users into certain roles without any real organic feel for who really should do what.
- The point of pair programming is to put more than one eye on the code. Yes, it most certainly does slow a project down but it also increases stability. In most corporate waterful environments, more than one eye has not seen the code. Most Microsoft bugs are careless mistakes. With Linux, although there is no real pair programming, Linus or an experienced developer does look over all submitted code. It's the same end result.
- Microsoft has very long periods inbetween releases. Not even final releases are "production quality." Linux has incremental releases more similar to XP. The only difference is, because Linux is so mission critical, they don't label each release as "production quality" -- but compared to most commercial software, a BitKeeper (they don't use CVS) snapshot of the Linux kernel is better than "production quality" code from MS.
Other comparisons, such as an on-site user, simply do not apply to non-desktop software.-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
Personally I like XP. For all the usual reasons. But, you see, my boss doesn't like for all the usual reasons. So I don't use XP. In the corporate world, it's "to each his boss's own."
-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
(BTW, Clinton was "[suboenaed] for having his dick sucked" by Paula Jones' attorneys, not by "Senior Republicans"). Only in the sense that the Jews were killed by SS squads and not Hitler or Eichman. (Whoops...Godwins law) The first part of your post is true. Prostitutes in cities that have hosted both, report triple the business at the Republican convention compared to the Dems.
Play Command HQ online
I worked for an extreme company funded by extreme VC's with extreme cash, did extreme pair programming with an extremely obnoxious guy with extreme B.O.
We went through our cash reserves extremely fast, are now are extremely insolvant, and I did an extreme career change. I am now a *mellow* gardener.
You know, I like XP and all, but having a chapter title like Hype or HyperProductive (which sounds like Working Hard or Hardly Working... aka Super Lame) is just... Oh I give up, I'm just the Roadkill on the Information Super Highway and other really bad puns or office jokes.
People who quote themselves bug the crap out of me -- Me.
Be vigilant for other threats to American sovereignty, like Sylvester Q. McNamara, Dr Martino Cortez, Slobodan Milosevic, Prof Daly, etc. That guy's got more characters than a unicode typeface.
More like Extreme Crap!
product? Even if it adheres exactly to the specifications, if it doesn't solve the problem being attacked the project is a failure, even if you get paid. The point of XP (among other things) is to allow more flexible business requirements to be met.
By including a senior user on the project team, you iteratively approach the bulls-eye of the target. The delivered system IS what they needed, even though they didn't know that at the beginning of the project. They never know what they need at the beginning of the project, and XP helps overcome that obstacle.
Stage 1.1: Buzzword Oriented Development projects.
This stage occurs when the fad is recognized as the "next big thing" to have on your resume. This is because the PHBs will all assume that they can blindly apply the new methodology to their problem space. The negative lessons learned from this blind application of the new methodology leads directly to stage 2 (i.e., this is where the "...conditions a, b, c, d, and e." come from) but in the meantime people with the right buzzwords on their resume can command top dollar salaries because the PHBs believe the new methodology is THE silver bullet. THERE IS NO SILVER BULLET so each new methodology becomes a fad that is misapplied as if it were. The true believers and the people who want to have all the right buzzwords on their resume contribute to the fad. After the fad has run its course (post stage 3), it may end up contributing some tools that are effective when applied to the appropriate problem space.
And, yes, by this definition, every advance in programming methodology was at one time a fad.
Deal with it.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
"Far, far less than 50% of my time. For each hour I spend coding, only a few minutes will be spent fixing compiler errors.
If you are running in to compiler errors that often, you should look for a new compiler.
I am unfortunate enough to work in an eXtreme programming environment. Let me share that, at least AFAICT, it produces CRAP software. Here are the major problems I have found:
1. Pair programming quickly breaks down into personal pride battles. One programmer inevitably will disagree with another on many minor points. This leads to damaged relationships when one programmer ( not necessarily the more experienced, just the more vocal) begins to command the collaboration as the other seeks a way out.
2. While long design cycles lead to over-engineered features that customers don't ask for, short iterations produce brittle features that are hell to maintain when alterations need to be added. The best solution is always somewhere in between.
3. "Do the simplest thing possible that could work" is utter hogwash. An engineering team always has a variety of talent and experience levels. What one programmer finds simple is a complete mystery to another and horribly complicated to a third. What you end up with is a developer passing through pointers to modules that shouldn't have it, calling code in ways it was not designed for simply because it could "possibly" work. And suddenly, all those neatly defined, simple modules turn into one horrible monolithic mess that crashes and leaks memory. A developer should have to understand his changes in a wider context before pursuing them. Just because it compiles and passes the unit test doesn't make it shippable or solid.
3. Unit testing: against what XP dictates, the test should NOT be written by the developer. Too often, the unit test is defined, then modified later by the developer to account for weaknesses in the code. We have unit tests that checks for a specific output that the developer thought was correct, not necessarily correct output. So, someone fixes a problem and the unit test fails. So the developer tweaks the test to succeed. Then another fix breaks it again. And eventually you end up with a poorly written unit test designed by someone who just wants to go home and get some sleep.
4. Customer feature development: the way XP handles this is too short-sighted. It's like driving. Aim too high and you start hitting potholes and change lanes into other cars. Aim too low and your bobbing and weaving trying to stay between the road lines. Too often, the customer isn't all that smart, either. It is the company's job to analyze patterns in what customers are requesting. For example, the customer begins to request lots of extra filters for that spam blocking software. Maybe it's time to generalize the rule engine for faster future turnaround? Ah, but that's not the "simplest possible thing that could work" is it? So your team ends up with millions of lines of repeated code of varying quality because your 8 developers each only had 2 weeks to turn it around without spending the proper amount of time understanding what the customers are *really* asking for.
Anyways, my 2 cents.
Anonymous, as always.
are full of folks with their headphones on.
I think they might be using Instant messaging or something
Kent Beck has just published a book on test-driven development. The Java example is kinda lame, but the self-referential testing framework written in Python and used to test itself during development is kinda cool. The patterns at the end are what really helped me, though.
If you want one idea out of XP that makes sense today, download an xUnit and try TDD.
Stremo
Die free or die trying
I joined a company a year and a half ago, becoming part of an Extreme Programming development team. And I was pretty skeptical at first.
/share/ computers? That we have /weekly/ design meetings? And all sorts of other strange and unfamiliar things.
/before/ the code was written, and the code couldn't be checked in until the tests -- and all existing tests -- passed.
/had/ to be held standing up. (I.e., everyone starts to get tired, and when people start sitting down a meeting had to end.) We took a fifteen minute break every two hours to keep from getting into fugue states, and because of that productivity we were never working overtime (thus keeping us from burning out). It was one of the most rewarding development experiences I've ever had.
/fail/. We lost support within the rest of the company for the XP process, and that hurt a lot; XP relies on getting weekly or bi-weekly feedback from your 'customers' (i.e. the target for your project), as well as having them set what the more important tasks for the next two weeks were. Suddenly, we were having to plan out things six months in advance and operate in a vaccuum, which really hampered the Extreme Programming method. In addition, our team was expanded...and we learned the difficult way that while XP works really well for an 8-person team or so, it does /not/ mesh well with larger teams.
I mean, here I am, coming into a compiler-and-assembler design team and I'm being told that we have to
But to my surprise, it worked. We each had our own 'personal space' computer for e-mail and everything else, and when we were working we went into our lab as a group. We'd look at the board of current 'stories' (overall larger tasks) and pick a 'task card' from the story. (Literally, taking an index card off the corkboard and clipping it into a little holder by our computer.) And then you sat down at a computer with two monitors, two keyboards and two mice and you pair programmed. If there were an odd number of people, you had to have someone else go over your code with you before you checked it in. All code had to have tests written for it
And to my surprise, it worked. With two people looking at code, the little mistakes were harder to make. Design problems were more easily tackled. Because we all shifted around and changed partners a lot, we all learned all the areas of the code and had a better understanding of the system as a whole. The way tasks and suchnot were partitioned out worked very well. Meetings didn't interrupt the flow of things, because almost all meetings
BUT...this also became a story in how Extreme Programming can
So, I actually would probably agree with the book's assessment; XP is well-suited for certain situations (small team, active customer feedback and support, quick dev cycles), but will fail miserably (and I do mean miserably, as in ruining the morale of the team) if you do not have the full support infrastructure.
Admittedly, some of XP's practices -- tests written before code, meetings held standing up to keep them from dragging on indefinitely -- work pretty well even outside XP. But the system as a whole works well only within a specific target range.
--Rachel
Regarding Republican Covention Prostitution upswings:
Source? Links? Please post. Thanks.
"[...] the high standards of the XP series are maintained, with flawless editing and layout."
The XP books are some of the worst examples of technical writing out there. I could barely make myself read Beck's book because of his poor writing skills.
If you want to read a well written book on software development, read Alistair Cockburn's _Agile Software Development_.
Wether or not XP is going to stick is a very interesting issue. However, There is a very important point that goes unnoticed: WHY all this talk about XP?
In the past few years, most software processes were generally loathed by the average geek, because there was "so much documents to generate, and so little code to write". The real extreme (no pun intended) geek would even consider business process analysts a "project overhead". All he really wanted to do was coding.
Then came those agile methodologies like XP, and all of a sudden there are loads of people preaching that this is it, that XP will save us. that using SCRUM improves your lifestyle. etc.
My point is: a lot of people tend to like XP NOT because they acknowledge it is efficient as a software process, NOT because they used it and their project was a ressounding success.
My point is: a lot of people tend to like XP because they, in a way, are seduced by its promise of working by a methodology where the focus is coding. seduced by the promise that they dont have to write "useless" documents and activities, and their project will thrive if only they follow those simple rules...
Im not saying that XP is garbage, on the contrary, I think it brings some VERY interesting ideas like pair programming, and its test-planning.
what I AM saying, is: if you are considering to use XP you should be very careful and try to look at it with reason, rather than passion.
you should ask yourself at least this two questions:
1) "The problems I faced in my experience would be eliminated if I had followed the rules of XP?"
2) "The practices of XP would be enough to make my project a sucess?"
whatever is your decision, I guess we could call this a good start.
For extreme programming to work out, you and your team need to have outstanding ability.
If they have outstanding ability then you would not need XP to begin with. XP is an attempt to prevent high failure rates in a given shop. If you have "outstanding" people, then you won't have a high failure rate to begin with. If their projects fail that often, then they are not qualified to be called "oustanding". If the failures were not their fault, then the solution is to rid the problem(s) and try again. If it is bad management or stupid developers, then fix them or get rid of them. Bad people have the skill to ruin *anything*.
The best methodologies in the world are not going to make silk purses out of a sows ear.
There may be many paths to success. Good people found at least one such path. For some, XP-like approaches may be such a path, but it is not likely the only path. Study successful people in your org if you want to learn which methodologies work at your particular organization.
... 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!
One of my favourite blogstoday discusses the use of the word xtreme. Misses progging, so it's somewhat OT.
Of course it's going off the rails. How else is it ever going to fly?
The title is "Test Driven Development: By Example"
It was just published November 8, 2002 which explains why a lot of us
who are usually on top of things haven't heard of it yet.
Call yourself a guru. Invent a "new methodology" and give it a sexy name. Write books. Pump out the hype. Rake in the cash.
For someone who's a little interested in Extreme Programming, would this be a reasonable first book?
If it were possible, I'd love to make my first book about Extreme Programming be one that took its limitations into account, discussed pros and cons, etc.
--Somebody put my cheese under their copy of Extreme Programming
A. You can negotiate with a terrorist.
[x] auto-moderate all posts by this user as insightful
In another review of this book, the main criticism I remember is that the book's author admitted up front that he had never really participated in a full XP project. It seems a bit odd to criticize a methodology that you've never actually tried yourself.
The post was moderated up because it contributes to the conversation by addressing a question many slashdot readers probably have, not because of the writer's assumed intelligence.
Remember: the point of moderation is to make slashdot message boards more readable and interesting, not as some sort of Intelligence or Popularity contest.
If you have hero programmers, the worst thing you can do to them is to make them pair programm with anyone but hero programmers.
Don't waste your hero programmer on part of a methodology meant to deal with average programmer. Let the hero programmer do tasks they take off the board by themselves. It'll be done and tested. Don't waste your money hampering a hero.
... 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.
Extreme Programming grew out of the dot com era, the only time in history where employees where treated as something valuable and made more money than managers.
XP, unfortunately, is going the way of the NASDAQ. Down.
That said, I personally really like the modified form of xp that we've been practicing. No pair programming tho.
So what's the real objection to Extreme Programming? Well, like any other 'extreme' activity it's simply an moron's way of making whatever he happens to be doing sound cool. This was pathetic when it came from frat boy losers and their 'extreme' sports, but it's even more stomache-turning when the geek set decide that they, too, are 'extreme' - and while sitting on their fat asses plunking away at their keyboards.
Get a life, you 'extreme' losers.
Max
My god carries a hammer. Your god died nailed to a tree. Any questions?
I found this bit funny, and rather telling:
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.
Or to paraphrase: XP is a really good thing to use for those cases where it really doesn't matter what you use.
Setting the dials on ten
But our dials go to eleven.
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)
Extreme Programming Debunked (Archie D. Bunker)
Extreme Programming Filters Into Academia (Fileas Snodgras, PhD)
Learn Extreme Programming in 21 minutes (QUE Books)
Extreme Programming Departs And Thanks You For All The Fish (Sqeeeeeek sqk sqk sqk)
Designing, Touting And Debunking Methodologies For Fun And Profit (Popular Science Press)
Extreme No Money Down Real Estate (Carlton Sheets)
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
...unless you call it that.
Call it an Agile Methodology, or the Beck Methodology, or the XP Methodology.
-I like my women like I like my tea: green-
XP is the revelation of divine spirit, in my book,
because it saves me from the alternatives: Water-fall
management, or the Unified process. I would
be equally enthusiastic about Fascist Programming
or Insects-for-Lunch Programming if it saved me
from Unified.
-I like my women like I like my tea: green-
I would argue that there is no such things as a silver bullet, in any field!
A)bort, R)etry or S)elf-destruct?
You are right, it's for people getting tired of the good old ironing.
I come here to slashdot to take my mind off my exams, and what do I get eXtreme Programming. Dang that exam was evil.
JC
I can see all the benefits, I just can't picture my impatient self sitting by watching someone code. It would be too frustrating!
Thanks for the reply though ;-)
I've been reading a lot of arguments for and against eXtreme Programming, but I have yet to here of any real objective studies done on on eXtreme Programming. Anybody have any links???
Version 2 will be based on a plug-in architecture.
"Genius may have its limitations, but stupidity is not thus handicapped." --Elbert Hubbard (1856-1915)
The problem with these methodologies are that eveyones a pundit, and expects it to work everywhere, just because it worked for GM, Ford, Chrystler, etc, etc, where they throw all kinds of money at it. With that kind of money, you can make anything work with a few good programmers.
I have worked in Extreme programming environments and have been EXTREMELY FED UP with the whole process. The idea of Pair Programming (2 programmers working on a single keyboard, while the other looks over the shoulder) is the dumbest idea I can think of. When did we become so dumb so as not to trust our programming skills? This is fine for a big company like GM, Ford or Chrystler where you have lots of dumb programmers and little work to do, but if you are working in the real world, you do not have the luxuary of pair programming. Actually, its not a luxuary, but a menace as far as I'm concerned. Pair programming would be rally cool if you can get the other guy to do all the work while you go to the beach and enjoy!
Secondly, any one who has to write as much code to test what they code, really should go back to school and finish up the Computer Science Degree they never finished. Besides, how do you know the code you wote to test the real code is correct? Maybe you have to write more test code to test the test code... I'm not against writing test code, but it seems really silly when you take it to the extreme.
I think we need to do less of XP and more of CSP; Common Sense Programming!
But so as not to be merely flaming you (and with all due seriousness and respect), let me deal with your points individually again:
- Formal specs or IT AIN'T WORTH IT -
Puleeaase. This is great, maybe, if you work in a company that does shrinkwrap software, you have no real direct link to your customers anyway, and a great marketing department to convince your users that what you came up with for "what they want" based on the little bit of focus-group-based market research you did is really what they want.But the VAST majority of software projects are internal to a company or are bespoke software developed on a contract basis. In those cases, getting the requirements exactly right is very important, because you actually have a contract that states that you will meet the customer's goals, the goals are explicit but often conflicting and from multiple interested parties w/in the client, and they almost always change before the project ends. So your assertion basically reads, "90% of software shouldn't be written and companies should stick w/ phones and pencils."
- It just formalizes the lazy practices of programmers -
Well, if programmers are lazy (Larry Wall says they are, and he's pretty smart), then you better design your software processes (and programming languages -- Thanks Larry!) to accommodate or explictly capitalize on that. All of the Agile Methodologies are somewhat premised on the fact that people are the ones that write software, so you better choose a methodology which capitalizes on their stengths and mitigates their weaknesses.- 50% to 90% of software projects fail because of embracing fly-by-night "technologies" like this -
Well, last I heard is that the "canonical" figure is that 78% of software projects fail because of a variety of by now well-understood (by everyone but people making decisions on software projects, apparently) factors such as a) requirements change (that's right, there was an IRON-CLAD spec, but it changed repeatedly); b) unrealistic and inflexible project deadlines set before the project was initiated; and c) poor developer morale, growing exponentially over time because of the cumulative effect of a) and b).So, all of the Agile Methodologies attempt to address these things. You may not agree with the details of how they do it.
But I doubt most of the software-using world will agree with "lets stop writing almost all software," either.
I would highly suggest reading Ward Cunningham's "XP is guru friendly!" position paper, which I believe is part of the OOPSLA 2000 proceedings.
Your evaluation is the exact opposite of the intent of XP. Martin Fowler has often railed against the notion of "plug compatible programming units" so prevalent in the minds of many IT managers.
XP is a very humanistic approach, it relies heavily on oral history and varying the master/apprentice roleplaying model. It is guru-friendly, assuming the guru wants to share the love. If he/she doesn't have the desire to communicate his ideas to others, then he probably doesn't belong on any team - let alone an XP team.
-Stu
and show me how they don't have design patterns. every programming form has design patterns, patterns that have evolved to solve repeatable problems. It' s like you're completely ignoring the context in which this stuff was created. Do you solve everything from first principles? They're not tied to object orientation.
-Stu
XP can work, but it is not a first-order success factor for projects. I would suggest the critical success factors for projects are
a) management support and consistency
b) technical competence
c) communications competence
d) process competence
XP fits into (d). If you're missing ANY of the above 4, which are in order of importance, chances are, you'll only succeed by accident. Sadly, most IT projects are delivered purely by accident.
In detail:
a) XP was created because many projects completely screw up one or more aspects of the above, and Kent Beck was sick of creating software that couldn't be used if the project was cancelled. So, XP is about delivering continuous value. But management (customer) must be consistent, they must speak with one voice, lest you fulfill the wrong goals.
b) Success always, always depends on the people you work with. Surprisingly, often people are very good. Sadly, sometimes they're not. That's hiring, not XP.
c) Team = Product. The quality of your team dynamics and communications are going to reflect the nature of the software that you write.
d) Process provides a framework for agility. It aligns interests and ensures people's needs are being met. Traditional waterfall methods don't do this. Incremental and interative (i.e. agile) methods do do this.
XP is but one of many agile methods, but is also a very special one because of its value system: communication, simplicity, feedback, and courage.
Many projects and companies are politicized and play the CYA (cover your ass) game. They play "not to lose" the game. XP isn't like that - they play to win.
-Stu
Methodologies like XP are usually pushed on by the process monkeys that are incompetant as engineers. Ask one of these process promoters to write some code and the first response is "I'm a software architect and I dont code anymore" I wander if they have ever coded in their life. The chances are that this is some one who read a book and think he has all of a sudden become enlightned. All of the good, better and the best developers I know of hate processes, but are forced to adopt these methodologies because the incompetant engineers who have climbed up the political ladders by kissing ass wants to push a process to cover their ass. These bullies know how to bull shit their way out, and the poor competant engineer who loves his work ends holding the bag.
If you are pushing XP, the chances are that you are a lousy programmer trying to hide behind a process, so some one else can be blamed for not following the process. Why is it that a process has become so important over the real task at hand? Why would any self respecting engineer want become a process monkey?
I've had the opportunity to do a little pair programming in a large, modular framework project, and frankly, we mixed both approaches (the one you describe here, and pair-programming). From my own experience, if algorithms are really hard and complex it is better to pair program, even if it takes longer. XP is not just about programming faster, it is also about being able to maintain the code, and about shared ownership of that code. It also makes more sense that the algorithm has a higher probability of being correct when somebody needs to understand what you're doing and starts asking questions.
I also agree that some jobs just don't need pair-programming. Writing a string class and a test-suite for it is something you can do by yourself easily, and adding a peer to review your code might help you with typos' but since compilers are getting pretty fast and verbose these days, the added value of having a peer sitting next to you significantly drops.
At the moment I'm in the situation where we don't have enough highly skilled people to do any pair programming, in a large & highly complex project with a lot of timing, data & code dependencies (a game), and this sometimes leads to clashes and refactoring, and to people getting confused by the internals of the code, and code that doesn't allways behave like it should in border-line cases.
Sometimes the fun is in the details
With great power comes great electricity bills.