Extreme Programming... dood

This was mentioned in a few of the C++ threads, thought I’d see if anyone had a good reading list for it, as I still have no idea what it is.

I wouldn’t worry too much about it. It’s the latest fad in corporate America’s quest to hire programmers with no experience, 2 year degrees and low payscales and then get them to somehow write complex code as if they all had 10+ years experience, a masters degree, and a clue.

That’s not to say that there aren’t a few good ideas in extreme programming, but I don’t ever see it catching on in a big way.

It’s a particular software development approach, based on techniques such as pair programming (two programmers working on the same part of the code, one is programming while the other one is checking, testing or pondering test scenarios) and whatnot. You also might want to call it a cooperative take as the user/customer is part of the development most of the time. It means that he can see what the developers are actually doing, comment on that, suggest things and whatnot. The developers aren’t a black box to him. In other, older development models the involvement of the customer stops at the point where the specification analysis is complete.

You can find more information at sites like this, AFAIK XP has never really taken off though.

I think the reason for this is cultural. There is a pretty significant amount of inertia embedded in the collective mindset of IT professionals along the lines of:

  • design up-front is the preferred solution (even though it’s been demonstrated over and over that this just rarely works)

  • maverick programmers don’t like losing code ownership and don’t like working with others

XP is amazingly effective when there is buy-in, but unfortunately too many people don’t buy into it since they think it’s a “gimmick”.

Maybe it would catch on better if they came up with a name for it that didn’t imply piercings and spiked hair.


Maybe it would catch on better if they came up with a name for it that didn’t imply piercings and spiked hair.[/quote]

How about “Agile” development?

Pair programming is too expensive to ever really catch on for anything but war room solutions of single problems (regardless of effectiveness; there’s no way you can convince business to make changes like that)… The agile thing tends to get used by already not that healthy organizations to give up on specifying what they’re trying to accomplish up front in the first place.

I always called it tutoring.

The Software Reality guys have written a book about the hype, and also the occasional article.

Really an unfortunate name. It conjures images of a programmer being pushed form a plane with his laptop at 10k feet and having to debug a code segment before his parachute opens. You can imagine my relief when I learned that Vince McMahon had nothing to do with it.

I don’t really agree with the last part. I’ve seen it used to very good effect by teams that were quite sure what they were doing.

Agree on the first part, though. For the most part, businesses would rather have twice as many projects that take 3 times as long to get done (or which are never done well) than invest in pair programming. It comes down to managers preferring to say “yes, my people are working on it!”

It also forces too much consciousness of who’s good and who isn’t. It’s a lot easier to hide the weak programmers (rather than deal with the issue) when fewer people see their work.

It depends on the problem also.

I work in embedded spaces, currently for very expensive things that go on airplanes in which software is an equal partner next to electronics, optics, and mechanics.

People would point and laugh if I suggested Extreme Programming.

To be fair, so would Kent Beck (the guy who coined the name Extreme Programming). The whole idea behind XP is that it is often inexpensive to make simple changes to a software application. It is often no more expensive to add a feature to a business application after the first release than it would be to create it from the start. In those cases, XP can be a cost savings because users often change their minds about what they want a business application to do after they’ve had a chance to use it for a bit.

If you are doing something where those basic assumptions do not hold, then by all means, DON’T attempt to use XP. It’s never been advertised as a one-size-fits-all solution for software development.