Slashdot Mirror

← Back to Stories (view on slashdot.org)

eXtreme Programming (XP) in OSS projects?

Posted by Cliff on from the different-development-paradigms dept.

ivi asks: "I first bumped into the XP approach to system development, some years ago, on Dr Dobbs' now-defunct Seminar-On-Demand site TechNetCast. XP has some short, simple rules for growing software from Users' Stories, eg, with programmers working in pairs, showing prototypes to Users "early & often" et al. Download this XP site (under 400KB, zipped) for more. So, who's used or using XP, does it work for OSS projects & what have your experiences been with it, so far?"

1 of 60 comments (clear)

  1. Probably not a good match by David+Byers · · Score: 4, Insightful

    If your open source project is being developed by a team of people all sitting in the same building, directed by a customer who's paying for the software and who accepts XP, then yes, XP should work just fine.

    If your open source project is being developed by volunteers all over the world in different time zones, then forget it. Getting XP to work in that situation is probably possible, but difficult and probably expensive.

    But if you, like so many others, are using XP as an excuse for shoddy development practices (the "look, we don't need to do requirements analysis or design or documentation because we're using XP" syndrome), then by all means go ahead. It'll work just fine as an excuse.

    So let's get to the details. I understand XP pretty darn well. We deployed it successfully at my shop, making all the classic mistakes (and some of our own) on the way. We finally got everything right, and once we did, it worked really well.

    I'm going to assume that "open source project" means a project with volunteers all over the world (or all over the country), and no paying customer.

    Problem 1: The customer role

    The "customer" in XP is a person who represents the users and can make decisions regarding what to implement and when. It's not necessarily a paying customer or an outside person.

    The customer is a key person in XP. If you don't have a customer, you can't do XP and if the developers don't do what the customer requires, you can't do XP.

    Developers don't make good customers. They're too involved in the technical side of the project and rarely prioritize well. You really need an outsider who is focused only on the end result.

    Developers have to listen to the customer. The customer decides what gets done. The developers have no choice in the matter. They can tell the customer how much it will cost to get something done, but in the end they have to do what the customer wants.

    Do you have a customer on your project? Will your volunteer developers do what the customer wants? If either answer is no, forget about XP.

    Problem 2: Pair programming

    Pair programming gets left out of a lot of XP projects. That's unfortunate, because pair programming is a key ingredient of XP. Without it, the process hobbles along.

    There are lots of reasons why people give up on pair programming. The poster mentions one: not leaving that big programmer ego at home (it's just programming, not personal). There are others.

    What you need to understand is that pair programming is how knowledge and skills are communicated in an XP project. Pair programming compensates for lack of formal design and documentation. Pair programming cuts down on both trivial and serious bugs (the brain not writing the code is usually thinking about the big picture). We found that code written by pairs was consistently better by all subjective and objective criteria we used.

    Can you do pair programming in your open source project? If your developers are all in one place and work at the same time, then it's easy. But if they're not, you'll find it very difficult. Instant messaging or even speakerphones don't really help much. And remember, pairs are supposed to be unstable. If you always work with the same person, you'll lose a lot of the benefits of pair programming.

    Problem 3: Communication

    XP developers tend to be pretty chatty, in my experience. At our shop, verbal communication was a very important component, and to ensure that it was easy, we all worked in the same room (no partitions at all).

    How easy is it for your developers to communicate? Instant messaging helps, but isn't all that good since you can't count on instant feedback. A phone works pretty well, but it should be a speakerphone (a headset is OK, but less effective). Are your developers working at the same time? If they're not, how are they going to talk to each other while they work?

    In conclusion . . .

    T