The second edition of ‘Extreme Programming Explained: Embrace Change’ explains how and why to use XP. But where to start? XP Explained uses the analogy of entering a swimming pool to describe how organizations get started with XP. There are toe dippers, racing divers, cannonballers, and all manner of variations in between. In this paper Kent Beck and Cynthia Andres characterize these styles.
Getting Started with eXtreme Programming
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
There is no such thing as extreme programming, anymore than there is anything extreme about Mountain Dew Livewire.
Is it just me, or are they *really* plugging the book… Stinks of a commercial in the guise of an article.
As for xP: Tried it – it’s a fad.
Finsh and release an app in 3 months.
Then you get 10x more XP when every single one of your customer needs a patch because your product doesn’t work.
As ‘M’ states, XP is simply a fad. Too many programmers live by these principles as though they are a bible. I’m gay.
is that Extreme Programming. I’m suprprised I haven’t seen it there yet.
Yeah, I could imagine some pretty hilarious Dilbert cartoons focused around XP’s “pair programming” in particular, LOL.
is most interesting to those engineers who are better at talking than doing, the self-professed big picture types who don’t want to be bothered with learning the craft. They’ll make sure they’re paired with a better programmer, then they’ll take the lion’s share of the credit.
Can you imagine convincing Donald Knuth to “pair author” one of his algorithms books?
Actually, there were two or three Dilbert cartoons about XP a couple of years back. I remember that Dilbert ended up paired with Wally (but of course
Here is one:
http://weblog.cemper.com/a/200312/08-dilbert-on-extreme-programming…
The first in the series appearted on January 09, 2003.
Hold on, was that Wally talking about ‘doing that Tiger staff’, or something like that, in his status report?
Here are all three:
http://rockfish.cs.unc.edu/COMP290-agile/dilbert-XP-1.gif
http://rockfish.cs.unc.edu/COMP290-agile/dilbert-XP-1.gif
http://rockfish.cs.unc.edu/COMP290-agile/dilbert-XP-3.gif
greg: No, Wally was talking about something completely different
Of course, the second one should have been
http://rockfish.cs.unc.edu/COMP290-agile/dilbert-XP-2.gif
In your haste you made an error on your link…
Perhaps your posting partner should have caught it
There is some real gold with the XP way of doing things. Particularly unit testing and the design-code-refactor cycle. Any professional would be foolish to write this off without digging in a bit.
The waterfall way is dead. I just here cruel laughter every time 50 pages of requirements doc, functional specs are made useless in an instant of the boss figuring out that ‘Hey that won’t work, we really mean do it this way.’ The old 90% done forever method has nearly killed the CS profession. Static methodologies are out kiddies, agile is in. Live or die.
And don’t get me started on the ‘I code in my parents basement and not employeed right now because I am such a 1337 h4x0r’ it ‘professional’. I don’t want to upset any of the nice folks here.
BTW the 3rd dilber really made me laugh.
Computer science is the worst engineering discipline. Think about a 100 story building crashing vs a OS crashing? If only we follow good design specs and invest our time in implementing something, we can make a stable system. The problem with that right now is the time to market etc, things change so fast so companies wants to get stuff out as soon as possible. Once this changes, may be companies will get back to basic engineering principles and design things properly.
That’s exactly the problem XP is supposed to tackle. Business moves fast so CS has to move fast as well. This is not going to change Ever! I gaurantee this.
Waterfall was designed to be used in military style develpment where each level of management must slowly approve what will be implemented, define it, and either not change or drop the whole thing. Business does not work like the Gov’ therefore waterfall is a failure.
I am not a strict follower of XP, or any other specific methodology, but some of it makes a lot of sense. First get a general overview of the problem by Talking with the people who the system affects. Not just the manager, but the actual people who will use the system. Write down the general points on notecards so that they can be easily shuffled.
Then figure out which note card is the most important or easiest to implement. Then design that note card. Then write a series of unit tests that will tell you that the note card is done.
Only after this will you actually code. Write code so that the tests will pass. This keeps things simple (I shouldn’t need to remind anyone of the KISS principle) and now you have cool Automatic tests that will tell you if stuff is working right. That’s right Automatic tests, no more clicking every button in a form after every change! No more making sure that the program doesn’t choke when you type a zero.
Now you have the freedom to go back and change around the code to make it more efficient. No more worrying that changing module Y might have a subtle effect on module Z. Just run the set of tests to tell if everything is working.
The point of XP is to right stable code and code that can be proven to be stable in an environment where the requirements do and will change.
Thank you,
MattK
kent, ward, and the rest of the gang deserve a bit more reward for all their efforts i do say.
xp, like any methodology, is ***highly dependent*** on the ***people*** who are implementing it.
with great people, xp is certainly a lot more fun than the rupperfall model. well, with any people, actually.
Computer Science is analagous to engineering in a universe where the laws of physics change every quarter.
MattK
that every methodologist (e.g. RUP) uses to compare his stuff to.
Unit tests as an acceptance test for code changes has been best practice for ages. The idea of continuous improvement, as in moving the system from one stable state to another in small, verifiable steps, is at least ten years old from my own personal experience. What’s new and noteworthy about XP is the notion of pair programming. Depending on the circumstances, this might work quite well – let’s say, game code where the development team consists mostly of kids in their twenties. One of its side effects is to dilute the notion of individual responsibility for a piece of code. So instead of racking their brains about how to make the design and code better, say during the commute home and while taking a shower, engineers might be tempted to switch their minds onto other things… they now “trust” (or acquiesce to work with) the process that occurs during the 40-hour week.
I see pair programming as having an effect of regression towards the mean, in that it would help mask or mitigate the weaknesses of poor engineers while diminishing the craft and motivation of strong ones.
Computer Science isn’t an engineering discpline. It’s a mixture of topics in applied mathematics.
Topics in computer science can be used in engineering software for solving problems, which is something different.
A lot of the slop businesses have written to facilitate their main business goals aren’t “engineered,” but rather are massaged into various states of functional as is necessary for their use. Rules and goals are defined to varying degrees about what is to be accomplished and programmers translate them into software. There isn’t necessarily any detailed analysis for correctness, problems aren’t necessarily defined in minute detail, and so forth.
Some problems require correctness and have inherently well-defined properties, while for others it isn’t cost-effective because the problem domain is incredibly complex, the problem changes frequently, or the problem just isn’t incredibly important. A lot of “IT” work probably falls into the last two categories. Often they aren’t bridges, so it isn’t necessarily as important if they “collapse” a few times along the way.
Incremental improvements of existing investments via refactoring and unit testing is a cost-effective mechanism to improve correctness in evolved systems that also has obvious benefits to development latency. They also predate the XP fad of the .com era, which always struck me more as marketing than an attempt to improve software development. Buzzwords to sell books, receive speaking jobs, and otherwise get businesses into a profitable “craze” about something that was telling them what they wanted to hear–namely that correct software could be designed quickly with some snake oil and common design practices.
The real problem with xP is dedication and cost of ownership. I have been forced into using two faddy design methodologies in the last 6 years, namely xP and the Rational Unified Process (RUP.) Neither were particularly useful because the retraining needed outwayed the benefit. It’s all very well in a small team, but in a company with 50+ programmers and business consultants, you try getting them all on the same page. Using both was a dismal failure because no one cared enough. Very Dilbert, I know 😉
Then again a watered down flexible methodology has worked for two years for me in a small team. Regular brain storming sessions, peer reviews, milestones, bytesized tasks. An awful lot got done that way.
I liked that post and clipped it for future reference in similar discussions like this as a good “textbook response” to the distinction between software development and engineering (no offense to Fox). Thanks.
Man I would have really though that this XP would die off by now. The first time I head about this was from some guy pushing it 2 years ago. It seems to be an alright idea for beginers only once you grasp the whole idea it become a very dumb idea. For one if 2 people have 2 computers and work on the same project they will always finish it faster than if they use XP. That is unless you hire shit programmers and then nothing will help. So thanks a lot guys for contributing another dumb idea and another useless book to the collective void … Meanwhile I’ll do something productive.
Man I would have really though that this XP would die off by now. The first time I head about this was from some guy pushing it 2 years ago. It seems to be an alright idea for beginers only once you grasp the whole idea it become a very dumb idea. For one if 2 people have 2 computers and work on the same project they will always finish it faster than if they use XP. That is unless you hire shit programmers and then nothing will help. So thanks a lot guys for contributing another dumb idea and another useless book to the collective void … Meanwhile I’ll do something productive.
> Waterfall was designed to be used in military style
> develpment where each level of management must slowly
> approve what will be implemented, define it, and either not
> change or drop the whole thing. Business does not work like
> the Gov’ therefore waterfall is a failure.
Actually, this is a common misconception. If you look at the original waterfall model as defined by the military, change is welcome at any point in time, *but* in order to make a change, you have to go through a change control process that effectively causes you to go back to the beginning, rework your initial specs, figure out the impact, and determine if the change is worth it. If you don’t do this for every change, not matter how insignificant, you’re not using waterfall. It’s a pretty heavy weight methodology, IMO, it only makes sense for mission critical business and military apps (especially ones that deal with the infrastructure).
Most companies I’ve been at tend to gravitate towards the spiral model (i.e. a series of waterfalls where change management is lighter weight) or the staged release model (add feature sets by certain mile-stones and stabilize them). These work well enough (if they didn’t the whole software industry would have collapsed a decade ago).
XP is just one of the severial Agile development models (others include SCRUM and RUP). It has a lot of good and sane ideas. It’s perfect for some situations and some languages, but taking it as gospel for all situations is as foolish as using waterfall for everything.
As always, even if a hammer can be used as a screw driver, it doesn’t mean it should be.
Inertia is a powerful force in business. Being dictated to switch methodologies several times could be damaging to any large team when they’re used to one way of working no matter what system is being used. Even programmers become comfortable in inefficiency just like the users we program for.
I agree that it doesn’t make sense to pair all the time.
However, I think that if you’ll actually try pair programming, you’ll find that it can be effective when working on complicated tasks or sensative part of the code.
Due to its core practices, namely TDD and pair programming, XP is not suitable for everyone. But that doesn’t mean that you’re less productive if you’re not practicing XP. I think the trick is to identify what works for you, given the problem domain, the team skill set and the team members personalities.
Complementing Harel’s comments, I think pair programming is nice when appropriatedly used.
In my project we usually do pair programming in the critical parts, it helps a lot, since while you’re explaning to your colleague why you think this and that should be done, you gotta think things more deeply through, and a lot of bad ideas are detected during such process. It also helps if the code in question is boring or too detailed, since it’s more motivating to have someone “pushing” you when the brain starts to get too tired, or we just switch the one typing when that happens. The productivity and quality gains are worthy, and of course it’s nice to have 2 instead of 1 programmer who understand this hairy piece of code.
But then again, my experience is with very small teams, I am not sure if this would work on big teams.
If nothing else, XP raised the awareness around Unit Testing, which I believe is a very nice way of working.
XP is principally good but it won’t work for everyone.
It is a bit like if everyone takes public transport, we will have no traffic problem. Good principal but it won’t work for everyone.
If you eat healthy and no fat, oil and junk food, you will lose weight. Good principal but not everyone can do it.
So if XP works for you, that’s great. But it may not work for everyone. It certainly won’t work for me.
Certainly a lot of people get a wedgie when talking about XP. The most important thing that I got out of XP was the idea of test-driven development. Some people poo-poo writing tests for software but then they’ve never watched the difference between a project that uses automated testing and one that doesn’t. You might disagree with pair-programming, but I think that test-first development is a more important concept that is certainly shouldn’t be blandly put aside.
Even Erich Gamma, who wrote the Forward in both versions of this book, admits right off the bat that he doesn’t use *all* the XP prescribed methods on his current project (Eclipse). I believe this is because it is *all* optional anyhow – use what makes sense when it makes sense. It’s not only about the method/tasks it’s also about the agility and end result. There is some fantastic advice in this book that reminds programmers to use simplicity.
I see pair programming as having an effect of regression towards the mean, in that it would help mask or mitigate the weaknesses of poor engineers while diminishing the craft and motivation of strong ones.
Many poster here seam to think of XP in a personal perspective rather than an organizationl one.
Strong programmers is not as desirable from a organizational point of view as you might think. What happens if they dissapear, who will be able to maintain their code? If a programmer is much better than his collegues, and he knows it, he will probably demand higher salery than his collegues as he knows that he can’t be replaced.
You are right, pair programming will even out differences in skill. This is not so much a matter of masking the lack of skill in some employees as to function as a continous education where knowledge is transferred betwen coworkers.
I agree with this post. All solutions aren’t considered successful based on the same set of goals…which means that engineering those solutions can be done in different fashions and still be considered successful. I don’t like the implication that engineering is only good if it follows a strict discipline when discipline is being defined as a rigid inflexible quality. Following a basic set of design principles is one thing, but there are many good sets of design priciples to be followed.
You might disagree with pair-programming, but I think that test-first development is a more important concept that is certainly shouldn’t be blandly put aside.
I agree! Automated tests is important The most important thing about test driven development is that it forces the developers to write testable code. That often means better code, with high level of cohesion and loose coupling. The tests also makes the developers more comfortable with refactorization as they the tests are there to make sure that things doen’t get lost in the process.
Being forced to write tests before coding also improves the understanding of the code to be written, and having real examples on how to use the code makes it easier for new developers to enter the team.
If you are at all interested in Extreme Programming, look at
http://members.cox.net/cobbler/XPDangers.htm
It is interesting that Beck and co. talk a whole lot about that first project that introduced XP, but never really talk about the disasterous result.
Every few years a methodology comes out claiming to change the world, but is really a scam to sell books. XP was that methodology a few years ago. I am really surprised that it is still around.
Kent Beck’s first XP project for Chrysler was cancelled because it failed to deliver.
These guys provide a realistic picture of XP in the book “Extreme Programming Refactored”
http://www.softwarereality.com/ExtremeProgramming.jsp
The best advice is to deliver iteratively, while developing good requirements, use cases, designs, and test plans before coding.