Fog Creek Software
Discussion Board




Extreme Programming

Just what the heck is Extreme Programming (XP)? I am tired of reading the allusive one-liners like, "XP is a methodology that empowers developers to confidently respond to changing customer requirements...blah blah blah..."

Sathyaish Chakravarthy
Monday, September 01, 2003

XP is a methodology for software development like Rational Unified Process (RUP), Microsoft Development Framework, Agile Modeling, and SCRUM.

There are many more - there are development methodologies that tend to be the favor of the month.

I am not an expert of XP... my understand from what I have heard is that it has rigid rules.

Methodologies are important especially in arger projects, but very often the development team will have developed sets of processes to best fit its products/needs.

Consulting firms may have to be more flexible to fit the methodologies of their clients.

A former manager of mine had very good advice - never trust a consultant who spend his/her time writing papers instead of actual experience.

He mentioned the above advice - as our bosses had bought into a software development methodology developed by a professor at University of Illinois (Urbana).

The rest, as they say, is history.

Ram Dass
Monday, September 01, 2003

Google is your friend.

http://www.extremeprogramming.org/

Philo

Philo
Monday, September 01, 2003

Google certainly might be, but I don't see any signs of bonhomie in the multitudinous links that it throws back at you, when all I have time for is to rummage through them. I was expecting someone would tell me like I were a four year old, about what's so great about XP. And is it something that's cropped up only six years ago? Or are they trying to make a fool out those of us who'd willingly subscribe to the wisdom of creative expounders of metaphysics who otherwise know very little of real life?

Sathyaish Chakravarthy
Monday, September 01, 2003

extreme programming is this thing, that is mentioned in a bunch of books, and also online. you can read about it, or talk about it, or do it. and stuff like that. if you are interested in that kind of thing, you might like to read more about it, but if you aren't interested in it, perhaps not reading more about it is a better idea.

my friend once wrote a computer program, and it worked ok. and he wrote it by himself. and other people liked it too, and they downloaded it, and used it, and stuff. i don't think he used extreme programming or even read the book, but maybe you would like to? in any case, the sun rose again today, and then it set. I woke up late, and will soon be going back to sleep, early. tomorrow i anticipate things will be similar to today, but maybe they won't be. good luck.

rz
Monday, September 01, 2003

Google search for "extreme programming" returns highly  relevant results. Why do you expect that Joel's readers would write a better introduction to XP for you?

One Dan
Monday, September 01, 2003

Extreme Programming is like TQM, CMM, ISO9001, and other "cool new trends" - formalization of something people have been doing for a long time.

In this case, XP most closely matches what has been referred to as "cowboy" or "guerilla" programming - the idea that you do not need ten volumes of specifications before building an entire application. However, it attempts to put *some* form of process in place to protect the investments of those who are paying for the software. :)

Philo

Philo
Monday, September 01, 2003

Thanks, Philo. So the idea then is to inculcate only as much of formality in the process as is required as a bare necessity than having it as a luxury. Does that resonate the idea?

Thanks once again for your time and patience.

Sathyaish Chakravarthy
Monday, September 01, 2003

There was an enjoyable feature article in last month's Wired magazine on the topic:

http://www.wired.com/wired/archive/11.09/xmen.html

Since I'm just as clueless about XP, I can't vouch for its accuracy. <g>

Robert Jacobson
Monday, September 01, 2003

Extreme programming is one of the "agile methodologies" that believe you don't have to get things perfect the first time.  They assume we've invested so much cash into productivity tools, that our mistakes now aren't so costly in the future.  In the past, elaborate requirement gathering and design were needed upfront because redesign costs ballooned quickly.  Now, with tools such as refactoring and unit tests, the costs don't rise so fast, so it's worthwhile to accept them and gain flexibility.

eXtreme Programming in particular is composed of certain useful practices that have their weaknesses, which work together to neutralize these weaknesses.

That's at least my understanding.  You might want to google "agile methodologies".  While eXtreme Programming looks hype-oriented, its creators explained hype was necessary to gain corporate acceptance.

Tayssir John Gabbour
Monday, September 01, 2003

Thanks, guys. I am begining to see shape enough to give me an incentive for further reading.

Sathyaish Chakravarthy
Monday, September 01, 2003

This will take you some time to work through, but gives an excellent insight into what the XP process looks like:

http://www.objectmentor.com/resources/articles/xpepisode.htm

Sam Livingston-Gray
Monday, September 01, 2003

Some things that Extreme Programming emphasizes:

- test first; before you write anything, write a unit test that will only succeed if your code is right
- constantly refactor; unit tests allow you to do massive refactorings and still be confident your code is correct
- short iterations; the customer doesn't know what she wants, so showing her something in a couple of weeks so she can change her mind is much better than showing her something after a year
- pair programming; (the part everyone spends time talking about, but I think is least important) two bodies in front of a keyboard, which means defects spotted sooner, always someone to brainstorm with, and knowledge of the code spread more evenly throughout the team

Now hopefully you won't have to wade through dozens of articles to sift this out.

Jim Rankin
Tuesday, September 02, 2003

I'll second Jim; it's perfectly legitimate to do everything else in XP and work completely solo.  I've enjoyed pair programming the few times I've done it, but have gotten just as much out of arguing design with my old boss in front of a whiteboard.

Sam Livingston-Gray
Tuesday, September 02, 2003


Here are my $0.02 worth as someone who's been using XP for a couple of years now.

1) XP is not the second coming. Anyone who tells you that is trying to sell you something.

2) XP is not an evil plot created by cowboy programmers bent on world domination. Anyone who tells you that is trying to sell you something as well. Most likely some consulting time and a competing methodology.

In it's heart, XP is just like any other methodology: it's trying to increase you, and your project's, chances of success by providing a set of practices to follow. For me, at least, what makes XP a little different is that those practices tend to be based on emphasizing successful habits and common sense throughout the development cycle rather than a rigid approach that zeroes in on one particular aspect of software production (say analysis and design). YMMV.

What do I like about XP? It emphasizes communication. It emphasizes teamwork. It flat out admits that we are not good enough to plan a 12 month release up front with any confidence. It also admits that, much of the time, we don't know what the customer really wants.

The best analogy for XP is the driving one: you don't drive from your home to work by creating a plan up front and executing it strictly. You drive by making continuous little corrections.

Now, if you CAN plan a 12 month release up front with real accuracy, if you CAN be sure you know what your customers want, then you have my respect. You also probably don't need XP.

anon
Tuesday, September 02, 2003

I did a presentation on XP a couplea years back:

http://www.csis.gvsu.edu/~heusserm/CS/XP/XtremeProgramming.ppt

The "Salient Details of XP" are probably:

-> Test-First Development.  Write your tests; they will all fail.  Then write the programs to pass the tests.

-> The Planning Game.  Features described on 3x5" cards and estimated in terms of 'points.'  After a few weeks, you see how many 'points' you have accomplished and use this to calculate your velocity.

-> Team Centric:  With Customer as a member of the team.  An On-Site customer to ask questions of when needed is a big part of it.

-> Quick Releases:  Release every 3 months or less.

-> Avoid Meetings: Standup meetings of 15 minutes or less, only when needed.

-> Refuse to Big Design Up Front:  Just Don't Do It.  Design it well, and it if needs to change, refactor it.

-> Pair Design and Pair Programming:  If 1 Person introduces an error every 20 lines of code, then 2 people should only introduce errors every 400 lines of code!  (OR something like that)  You get the jist.

There's a few more XP-ish things on my web site as well:

http://www.csis.gvsu.edu/~heusserm/CS/CS.htm

regards,

Matt H.
Tuesday, September 02, 2003

When I was doing extreme programming, I didn't realize it, and possibly the phrase hadn't been coined yet. Some of the formalized stuff described here isn't what we did (e.g. we never calculated our "velocity" or produced fancy metrics).

It's maybe worth considering that we just called it programming, without any cool moniker. We had real live customers, not a CD going into a box. The customers couldn't tell us exactly what they wanted, because they'd never had a tool like this before. and had no way of knowing. So we design and code to make a first guess. The customer uses it, then we design and code some more to make it work more like they wanted it.

It's worth remembering that this style of coding isn't a good idea in a lot of environments. This method is fine when it's a hundred users. It's not so good when it's a hundred thousand. The little error that you can tell a hundred people to work around until you get a fix will bring a hundred thousand to a screaming halt.

Clay Dowling
Tuesday, September 02, 2003

XP can be summed up in two words:

Feedback loops.

Richard Kuo
Tuesday, September 02, 2003

One of the nice things about XP is that many of the books on it are small and quick to read. I suggest Kent Beck's book "Extreme Programming Explained". It explains the methodology and the theory behind XP.  One of the goals of the XP processes is to make the cost of changing code a constant function (or near constant)  instead of the exponential function it usually is. 

If the cost is the same now as later you can concentrate on just what is needed now.

john
Tuesday, September 02, 2003

>One of the goals of the XP processes is
>to make the cost of changing code a
>constant function (or near constant) 
>instead of the exponential function
>it usually is.

THIS IS A GREAT QUOTE!

It allows me to explain in one paragraph why
XP enables 'simplest thing that could possibly work'
to work, instead of big design up front.

A lot of people get hung up on XP because they just don't think that simplest thing that could possibly work is a good idea.

Now I can explain it, I think. thanks!

Matt H.
Tuesday, September 02, 2003

[nod]
I had to deal with a process zealot at Camel. Really good guy, very++ smart, but I think fairly risk-averse, and believed that Big Design could ameliorate all risk.

Of course, I believe that Big Design *creates* risk, since when you find out on design day one that a fundamental assumption in your design is flawed, you've just wasted the entire Big Design process and you're *still* coding by the seat of your pants.

I think software design is Shroedingerish by nature - it isn't anything until you say it is, and the client's real requirements don't exist until they try the software and either accept or reject it.

So XP gets those relativistic stages moving in smaller chunks, meaning less lost time when something doesn't work or the client's unsatisfied.

Philo

Philo
Tuesday, September 02, 2003


I was once talking to some people at a shop that was considering XP. They described their current process, which was very front end loaded. As they described what they went through to get a feature to the point where it could be implemented I found myself just wincing. I was imagining times where something discovered during implementation would force a change in the design and all the up front work/time that would be wasted as a result.

It's a very simplistic way of looking at it, but if you ever find yourself in a position where losing all the time spent on design would REALLY hurt, then you may have gone too far. Better to do a little design, try out some stuff, do some more design, implement a little more, etc.

anon
Tuesday, September 02, 2003

[I had to deal with a process zealot at Camel. Really good guy, very++ smart, but I think fairly risk-averse, and believed that Big Design could ameliorate all risk. ]

Well, I'm risk averse too.

I'm afraid of blind alley designs that are too brittle to accomodate changes discovered during implementation.

I'm afraid of analysis paralysis.

I'm afraid of long, monolithic feature development tracks that leave me with no room to manuever if management cuts resources or time during the release.

I'm afraid of customers saying "that's nice, but it's not what we wanted".

I'm afraid of developers who hide in their cubicle for weeks/months on end.

I'm afraid of anything that has "Integration" as one of it's tasks.

A little fear isn't a bad thing. And the belief that you can ever totally rid yourself of fear in a software project is perhas the biggest illusion of all.

anon
Tuesday, September 02, 2003

Look:

http://www.onlamp.com/pub/a/onlamp/2003/08/28/extremeprogramming.html

The article also has the term "Open Source" in it, so you OSS/anti-OSS zealots are invited to drop some comments, too.

On a serious note:

http://linux.oreillynet.com/pub/a/linux/2001/05/04/xp_intro.html

Johnny Bravo
Tuesday, September 02, 2003

XP is far from a process. It's ridiculous to claim XP is just another method like UP or Microsoft method, even though to some extent I agree on practices of XP, but at least at the time being, XP is not a process, it's just a combination of a set of experiences.

And what's more, there are some critical issues with XP rules, for software engineering, the essence is to automate the creation process and lower the affect of man's factor, and reuse experiences as much as possible. But XP drive this process into a different direction, it severely increased the man's factor by 'postponed refactory', 'frequent release' and the said 'pair coding', all these activities will require  much more skillfull designers and programmers to get a good results.

Pair coding is cost and strange, I don't think any experienced designer would like to be gazed at when he's at work. Very extream crazy thought to practice.

x
Tuesday, March 30, 2004

*  Recent Topics

*  Fog Creek Home