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.
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?
. 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.
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'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?
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. ...not to mention reading and posting to Slashdot is really a one-person operation.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
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.
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..
That's not the way pairing is supposed to be done. Pairs are supposed to rotate among the team. People who smell bad, or simply can't learn to perform well, are supposed to be asked to leave -- not the capable folks like yourself.
> I've not met someone who can keep up with me when writing code.
So there are people on your team whose abilities are not on par with yours. You don't think that you owe it to these junior team members to mentor them and help bring them up to your level? That's a good chunk of what pair programming is all about. Also -- what happens if you are offered a better job/quit in a huff/are hit by a bus? Isn't it better for the whole team if some of those junior folk have experience with "your" code? If you work a little slower, but your knowledge gets spread around, the benefit to the whole team is much greater than if you work fast in isolation.
>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.
So the projects you work on have requirements that are frozen in stone, and designs that can be implemented in only one way, without change, with no thought involved? OK, then there are no decisions that could stand to be reviewed in real time. Everybody else could use some advice.
Cantankerous old coot since 1957.
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...
Didn't this get addressed in the old file "The Tao of Programming"?
(to paraphrase, since I don't have the original text handy):
A manager approached a programmer and asked how long it would take to build an important project. The programmer said, "Six months."
The manager said, "that's too long. What if I assigned two programmers to it?"
"Then the project will take a year."
"That's terrible. I'll give you four programmers!"
"Two years."
"Aigh! I'll give you a hundred!"
"Then the program will never be completed."
Dig?
Farewell! It's been a fine buncha years!
Stupid job ads, weird spam, occasional insight at
(I can see why you posted AC, because you would likely have been modded down.) Anyway, your observation matches my experience: at our shop we tried pair programming and it not only resulted in a fair slowdown, there were also other effects that we noticed:
- the pairs spent a lot of time talking to each other about off-topic things.
- it lead to the formation of "expertise" domains, where one developer would do a specific task because he was treated as the expert, when the other just sat nearby and stared.
- the number of bugs was not significantly reduced
- bad design was not eliminated
So what we do know is, we build small groups of programmers and give them a modular task. They can do as many meetings and talking and planning as they like, but then they distribute the work amongst themselves and get it done alone. The code is then later reviewed by a "review partner" from the same group. It works nicely!
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
Then I simply got up and left.
As far as the clarity of my code, if someone didn't pay attention in class or doesn't have the foggiest notion about what the STL can do, then why is it my problem? If they don't understand "Hungarian Notation" or MFC or even the base Win32 API, then again, why is it my problem? The goblin I was paired with supposedly had 5 years of Windows programming experience. Methinks he lied on his resume...
If I'm on a tight deadline to ship code, then the last thing I have time for it so break down the logic into small words for little goblins who don't understand the programming language. No, I'd much rather have a code review to where I can explain everything in great detail then trying to remember my place in my thought process and continually getting annoyed at the interruptions.
As far as your third paragraph - that really depends on the bug. If it's a trite little bug that takes 5 seconds to fix, then the time is far better then it takes to explain in small words to a goblin.
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.
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.)
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.
I've been involved with pair programming for about 2 years now, and while we don't do full XP style development, it has been extremely beneficial. We are both expert programmers, but I do all of the typing. The benefits are the ability to have conversations about issues the moment they are encountered. Rather than coding a workaround or the first thing that comes to my mind, we discuss it and the results are spectacularly better. We decide upon a solution and code that, generally much better than what someone would come up with alone. Ideas are questioned and assumptions are challenged.
He is also able to be giving me a constant just-in-time code review. We catch dumb mistakes that the compiler wouldn't, simply by having more eyes looking at the code. When writing test cases, we both come up with test scenarios that the other hadn't considered... as a result, the test suite is far superior to what it would have been.
Additionally, working in pairs means that more than one person knows the code. This is good for lowering the "bus count". (That is, how many people can get run over a bus before your project is seriously in jeopardy.) With more people understanding the code, I can go on vacation without worry of a critical bug being discovered, and trying to tell them how to fix it from a phone halfway across the state.
Yes, it does slow us down a bit, but I wouldn't consider it a waste whatsoever. It's an incredibly bug-free, totally reliable system. That means little to no time wasted trying to figure out crashes. The time is more than made up for when you consider debugging time.
My experience with non-paired programming does not have as good of results. Even if you threw out everything else about XP, the testing and pair-programming have been the two most valueable ideas it offers.
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).
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.
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.
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 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/
Someone with three questions like this:
:-)
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. gets modded as Insightfull?
He is not "cluefull" enough to make a google search?
Anyway: XP is set of about 12 "best habits" you should follow in programming.
Whereas other software developmnet processes focus on a lot of work wich is not programming, XP focuses on doing a lot of programming and incorporate the other work: analizis, design, as good as possible into the programming "phase/workflow".
The most known "buzz words" are programming in pairs and unit tests.
But: there are 12
-- Have your programming team at the customer side, or the customer in your house.
-- refactor, if you see a strange couple of lines of code, refactor it
-- only program what you imediatly need, Saying: "You ain't wanna use it". So don't program overabstraced "framework like" code as it likely will get refactored away or won't be needed anyway
-- use storry boards, similar to use cases, well in fact similar to Scenarios, but a lot of literatue mixes up the difference between Use Case and Scenario
-- imediat feed back: make a story board with the customer, see above, prepare a unit test for it, see above, code it, refactor every existing code in your way to support your new story, run the unit tests of teh old story boards to be sure nothing broke during refactoring, run your new unit test to your new story board, show the result to the customer, adjust storyboard and repeat if needed
-- plan the architecture, "play your way through it", buzz word: "planning game", e.g. use CRC cards
-- short releases, plan a day per "story board" or major feature
-- collective ownership, all code belomngs to the team, ther eis nothing like YOUR file/class or code
-- have a system metaphor, thats an architecture pattern, basicly have an other system you can compare your current work with
-- learn and communicate
Well, read a book, get a consultant and DO it.
You won't be able determine if it WORKS or not by trying it half hearted for 3 weeks.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
Try this link for a well laid-out explanation of what XP is and how it {does | doesn't} work.
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.
This page explains what XP is, yet after reading it, I'm more confused...
They must have written this using the eXtreme Writing technique.
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