eXtreme Programming (XP) in OSS projects?

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?"

Comments

Re:XP in college

[Nasarius]

The method you describe seems to be the most natural and obvious approach, especially if you're doing OO programming. I don't like pair programming either, but other elements of XP might be useful, like more interaction with customers and frequent milestones. No methodology is perfect for every team and project.

Re:Doesn't seem suited for OSS

[splattertrousers]

My initial impression of XP (I haven't tried it but had it explained to me) is that it takes a lot of the fun and programmer-as-artist aspect out of software development.

It doesn't take the fun out. It's all about making sure the developers develop exactly what the customer wants. The customer is the person paying for the project (or a duly appointed representative). I'm not sure who the customer would be on a distributed OSS project. Perhaps that role can't exist, and therefore perhaps XP is unsuited to such projects.

I can take your "programmer-as-artist" comment two ways. The first is that programming is an art, in that you can come up with creative solutions to problems and you can create a working system from nothing more than (sometimes vague) requirements. You can still do this with XP. In fact, it should be easier.

The othe way one can take "programmer-as-artist" is that the programmer not only decides how to do something, but what to do. In XP, those two roles are separated. However, a programmer could also be the customer. That would make sense on hobby projects and other projects where nobody is paying for the development to be done. If someone is paying for the development to be done, than that person must make quite sure that the programmer really knows what the program should do and isn't wasting time throwing in things that just might be cool.

Also it is good for making a larger number of so-so programmers as productive as a few really good programmers.

You say this as if it's a bad thing. It's a great thing. The average programmer is, by definition, average. (Okay, math geeks, you can chime in now about how it's only the mean programmer who's average, or whatever.)

XP worked for us

[StarBar]

We've used an XP like paradigm for about three years developing a Linux based distribution that rides in a custom hardware. I was comming in late into the project that had no structure whatsoever and a hardware already designed and was just about to migrate to Linux from some in-house OS so the situation were chaotic to say the least. The company I work for were a startup at the time.

The first thing I did were to picture the whole system as a group of functional boxes with interfaces. The next were to define the interface mechanism. Then I grabbed my nearest bosses and made them customers showing them a new release every two weeks. I distributed the tasks of implementing the functional boxes among the programmers in the group who I placed in the biggest room awailable facing each other. In the group we used nightly builds to always have the CVS build clean. My bosses were forced by us to prioritize among tasks and give us input for the next release. One day over a year later we could experience a decreased pressure and a product that we felt confident about. At that point we started to refactor all bits and pieces that were just implemented the easiest way as well as the build system. Now another two years down the line we have catched up and we have got rooms, some still with two programmers and we are increasingly using a traditional way of programming, with a spec phase, an implementation phase and a QA phase etc. We only kept some featured of XP that we like, nightly builds and refactoring.

I think that XP has its cons and pros depending on the situation. We could never have delivered all these demos, prototypes and releases during the course of these three years without XP, simply because we had to attract customers and venture capital all along. We didn't use XP to the full extent either, no automatic testing and no true pair programming but that was only because we didn't have time to change ourselfs. If you sit on a fully financed military project for instance I doubt that XP will work for you. If you lack time or funding or simply needs to go extremelly fast to something that works XP might be the way to go, just ensure that everybody in the project agrees.

Good Luck!