Slashdot Mirror
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?"
What happens is a company has a bad experience with programming -- say they fire some old guy to hire a cheaper new guy and discover the new guy can't make head or tails of what is going on. Of course the new guy says this is due to lack of documentation. Or a department realizes that some software doesn't do what they needed, because they never told anyone what they needed and no one asked. Or the realization that a key piece of software that is keeping the whole company running is a mystery to everyone who works there and the source code is long lost.
Well, managers can't really get paid the big bucks for saying "Hey guys, next time let's try to be smart" which is the real solution. So instead they invent a plan, procedure, or rules to prevent it from happening again. Everything you do must be documented. Tens of thousands of dollars on verson trackers. A flow chart describing a series of meetings to produce a requirements document and another flow chart for modifying the requirements document.
Well, pretty soon people realize you have a bunch of people filling out TPS reports and one productive guy who is evading all the documentation and requirements procedures and just getting work done, maybe protected and covered for by a few co-workers and a boss. And someone thinks, jeez, if only everyone was like him.
But you can't just have the managers go out and say, "Alright, bad idea, toss it all out the window, let's just focus on common sense, communication, and being smart." That kind of implies you could hire fewer managers and just spend money on trying to get smart people.
So you have to package the "common sense" proposal in a bunch of buzzwords that make it sound like it's a new 6 sigma or total quality or some other plan for extracting the most out of dumb people by telling them to do smart things. This way you can slip it in past the Organization Men.
One of the most pathetic things you can ever see is a stagnant ossified department, which long ago chased away anyone with any ambition, attempting to implement pair programming and other feature of common sense. If you program in pairs, it's harder to say that person X did this and person Y did that, which managers see as a threat. Talking with the final consumer also undermines certain people's positions, so they usually interpret that "show prototypes early and often" as instructions to go through a formal process of beta release, evaluation, discussion meeting, plan for addressing issues, FASTER. Not fewer levels of BS and more communication, just do it harder and more often.
Open Source projects are usually XP in an extreme way, except for pair programming. Almost all code is written by lone wolfs and casually reviewed by others if at all. Other than that, the quick-release and review, constant prototyping, etc all just naturally happens. Even more so since the programmer is usually the user he is trying to satisfy, which is the tightest loop there is.
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
So was divination by reading the entrails of a chicken.
Mea navis aericumbens anguillis abundat
Perhaps it was counterproductive for you, but I really like it and lots of other people do too.
Some of the other rules in the article are nice in theory, but not really practical in real life. For example: customers aren't always available, and often don't want to be either.
I would not want to work on a piece of software where the person paying for it refused to be around to help me figure out what it's supposed to do! If I just have to guess, then I'm going to be wrong and nobody's going to be happy.
Involving the customer too much usually ends up in them wanting something other than what they originally agreed to, but within the same time frame and for the same price
EXACTLY!! You've perfectly described the whole reason for XP. There's a reason XP's motto is "embrace change". Customers very often change their minds. You can say, "I know you're paying me, but too bad, you said you wanted X and that's what you're going to get." How does that help anyone? I like to say, "Sure I can change it."
(and then they get upset when they can't have it).
But they can have it! They are the ones who are paying for the software, and XP is all about letting them get what they want.
Well I wouldn't say we practiced "Xtreme programming" aka Agile somethingorother, but I did program in pairs for a while. It really isn't that bad of a deal. The trick is to lay out a basic skeleton first, so you know where you're going. Agile techniques aren't a replacement for good design. It's a method to see your design fail faster, therefore costing less.
I Browse at +4 Flamebait
Open Source Sysadmin
Having participated in a number of OSS projects, and even led/maintained a few, I can't see how Extreme Programming can help - the model is clearly better suited for in-house programming than distributed programming.
I was part of a group that tried doing an OSS/XP project. Your instincts about XP are pretty reasonable.
The main problem we had was getting enough of the team together in one place for long enough to make progress. XP really depends on proximity for communication; that's how it gets away without having any mandatory documentation.
On the other hand, pair programming really helped keep everybody in sync. People could turn up intermittently and that wasn't a problem; they'd just pair for a while with somebody who had been there the previous week.
Another piece that worked really well was mandatory 100% test coverage and test-driven development. A newbie could try out changes and find out quickly if they worked well with the rest of the system or not. And if a newbie somehow broke something without a test case catching it, the attitude was, "Well, I guess our test coverage wasn't as good as it should have been." It was nice for new contributors not to feel scared.
XP teams also have less "truck factor" problems than traditional teams do. A lot of OSS projects really depend on one visionary who does most of the work; on our XP/OSS project it wasn't a big problem if any single person took some time away from it.
Plus, it was also much more fun having a bunch of people in a room. Doing an OSS project solo can be lonely and disheartening sometimes; it was nice to get beers together after the coding sessions.