eXtreme Programming (XP) in OSS projects? 60
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?"
XP in college (Score:4, Interesting)
What worked MUCH better was designing the framework from the beginning, outlining how the different functions/processes/data structures etc. would have to communicate with each other, then splitting the programming tasks up.
After every one made progress, we'd recombine, work out bugs, etc.
Much more organic and realistic than the XP approach, which always seemed very articifical and limited.
Re:XP in college (Score:3, Informative)
Re:XP in college (Score:3, Funny)
I think this function should be called... (Score:3, Funny)
Re:XP in college (Score:4, Interesting)
Much more organic and realistic than the XP approach
Wow, I have the opposite impression. Designing up front feels inorganic and limiting, because you're making assumptions about the design that you either have to change in the future, or you have to force the problem to fit as you go along.
I guess in a college course it's easier to conceive the whole thing ahead of time. But for apps where you show it to a customer and he goes "oh wait, there are actually multiple properties per customer, can we go back and change it?" .. XP is wonderful for that kind of unpredictable development.. the customer is actually giving you feedback on every iteration.
Pair programming is a little difficult for some people, especially really smart people, but if you open your mind to it, it's really helpful. It minimizes bad assumptions, and keeps you from forgetting to write your unit tests first!
Just hoping you don't completely write off XP because it didn't work in that particular situation. XP is really just programming best practices with a faddish name.
Re:XP in college (Score:4, Funny)
Funny. I never had any trouble with it...
Re:XP in college (Score:1)
Re:XP in college (Score:2)
Re:XP in college (Score:1, Interesting)
Take pair programming for example. Many people have problems with pair programming because on guy is always acting as the back seat driver... constantly pointing out typos and blurting out method names as if it helps the other type faster.
The person who isn't typing is supposed to be looking
Re:XP in college (Score:2)
You do know XP was developed in the trenches, during a real-life project, by veteran programmers, don't you?
Re:XP in college (Score:3, Insightful)
Re:XP in college (Score:1)
Just because someone has been "in the field" doesn't mean that they know what's best - and people who think that need to learn more. Some of the stupidest people I've met have been in the "field" for 20 years. Why are they so stupid? Because they are so set in their "I have experience, therefore I know what works" mentality.
College students can make very good judgements preci
Re:XP in college (Score:2)
er... I think it is, especially in software development. In school, I never wrote anything longer than 5K lines, and never worked with more than 2 other people on the same code base. Since I've started working, I've been on servals projects each with 5+ people and 100k lines.
The difference in design techniques for the two are utterly incomparable. Unless someone in college had experience designing something that big, then they really
Re:XP in college (Score:2, Interesting)
Welcome to 1970.
There's a damn good reason nobody does that kind of design anymore on a real world system, and that is, in a nutshell, it doesn't work on any but a trivial system... such as you might do for a programming assignment in college.
If you're serious about becoming a good p
Re:XP in college (Score:2)
Most software is still programmed this way, because it works. XP is a fad that holds a smaller percent of the industry than Cobol. Of course you're not going to get everything perfect in the design- thats why you change it when it stops meeting your needs. Just make sure you have a reason to do the change first.
To be fair to XP, it does have some pluses to it- I like the increased emphasis on testing, even if I do think they take it a bit too far. But when you're working on code thats
Re:XP in college (Score:2)
Welcome to loud agreement. So you admit that top-down design never works in the real world and designs have to change as circumstances warrent? Why'd you bother posting such a cranky message when you agree with my point?
Re-read my post and tell me where I was advocating XP. My post was purely negative, as I've never actually tried XP and I'm quite skeptical about it in many ways.
Re:XP in college (Score:1)
My limited experience with pair-programming was quite the opposite. I felt I developed a stronger relationship with my programming partners, who were nearly strangers to me. Of course, we weren't forced into doing pair-work by some sadistic professor--we were motivated by an interest and curiosity. I've also found pair-programming reduces the Slashdot Temptation--the compulsive reloading of Slashdot and reading e-mail, which can be disastrous to someone with an attention as fragile as mine is.
Re:XP in college (Score:3, Insightful)
Re:XP in college (Score:2)
The pair-programming approach seemed to work much better. Once the deadline came (and passed) other groups were still struggling with trying to get their components to fit together properly,
didn't chromatic have an article on this? (Score:5, Interesting)
I don't have any experience with XP in writing open source projects, but I sure see a lot of projects that can benefit from it!!
I would love to see more software with comprehensive tests. It's very satisfying when you hack a minor change into a program and all the tests still pass. Then you can send the patch off to the author knowing it won't break anything (well, at least it won't break any of the tests
In this vein, I believe test-driven development (i.e., write tests, write any code that passes the test, then refactor to clean up the mess) is the most amazing gift from whoever the programming gods are. I'm glad XP has (re-)discovered it.
It forces much simpler, cleaner interfaces, and complete unit tests. There have been several times when I've wished that a particular open source program was split into many small objects that I could mix and match (i.e., I love this package BUT I need to replace the code that saves files to disk with code that saves files to a database..etc).
With TDD your design splits into many small simple classes. I think this would be great for OSS projects. A good example of a well-factored library (off the top of my head) is Mime::Tools for Perl.
Too many OSS developers think "I used Python, I must be doing object-oriented programming" or something along those lines.
Some other aspects of XP such as continuous integration seem useful.
Another thing about XP techniques (especially test-driven development again), is you can code in small bite-size chunks and not leave the code in a broken state. I think this is great for projects you might have "on the side". You can work an hour or two and your code will always be working and passing tests, none of these "egg-juggling" 10-hour coding marathons. You know what I mean, when you change something and it ripples to 20 files and you keep all the things you need to do in your head and you go half-insane running from file to file.
Pair programming, user stories, "Customers", etc., seems less useful.
But yeah test-driven development is worth trying, at least.
Re:didn't chromatic have an article on this? (Score:3, Interesting)
Well worth the read
Doesn't seem suited for OSS (Score:5, Interesting)
However, most OSS projects seem to be labors of love by groups of individuals working together in their spare time. I would bet most of the largest contributors to OSS projects are very good programmers who don't need to be "managed" to the extent that XP does. I don't see how many of the XP ideas could be applied when none of the developers are in the same room on a regular basis (or even available to meet on-line at one time), their time commitments are unpredictable, and in many cases have big egos and work on what they feel like, not what the customers ask for... After all, programmers have day jobs that are like that!
Re:Doesn't seem suited for OSS (Score:3, Informative)
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
Re:Doesn't seem suited for OSS (Score:2)
Hi! I'd recommend that you try it. I've done it for a few years, and my impressions are different. In particular:
is that it takes a lot of the fun and programmer-as-artist aspect out of software development.
This is certainly not the case on the projects I've been on. Why? A few reasons, I think:
In traditional proceses, somebody drops a big requirements document on your desk and then comes back in a year to tell you that what y
maybe they already do (Score:2)
Are those practices good? That depends on the specific people, user community, and the project. XP is no more a silver bullet than anything else.
Can't see... (Score:4, Interesting)
Many of the same techniques are used in OSS projects though. "Release early, release often" is almost biblical to people from what can soon be called a Linux-background, and another rule is "No functionality is added early.", which fits my personal design philosophy pretty well, and a lot of OSS projects: I can't remember the last time I added functionality to a program.
Re:Can't see... (Score:3, Insightful)
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 with
XP is just programming (Score:2, Insightful)
Smart (Score:2)
A hint to all those in companies now - if you see a company ossifying as described above, get out!! You owe it to your career and your spirit. I have seen too many fine developers wait years too long to get out of a bad situation, a terrible waste of an excell
XP!?! (Score:1)
Oh, wait, [i]that[/i] XP! Oh, okay, I feel better now. Phew...you had me scared for a minute there.
st00pid (Score:1)
Re:st00pid (Score:2)
Way To Complicated (Score:1)
A truly organic approach is the best way to program in a team. The people involved should and usually do develop their own system during a project. Having rules of practices that support and are supported is just way to complicated. No 2 people and no 2 teams will ever want to go at a project the same way, it makes teamwork tough enough. You should find a middlegr
Not too extreme... (Score:2)
My experience, after a good few years at it, is the same as what Lambent said - work on the design together, do tasks separately, and recombine. Pair programming works on certain problems, where one of the two has asked for help, but otherwise it's counterproductive and lets both parties get very annoyed with each other.
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. Invol
Re:Not too extreme... (Score:3, Insightful)
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
Re:Not too extreme... (Score:2)
Boy are you in the wrong industry. Your guess is correct but it's the universal framework you must work within - try to figure out a process that does make the user happy without them being present often. Don't make a process that requires people to change.
EXACTLY!! You've p
Probably not a good match (Score:5, 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
Re:Probably not a good match (Score:2)
I think that some of the XP practices can still be very helpful though. Test-driven development and short iterations seem like they'd work with a distributed team. Same with refactoring. Collective code ownership and continuous integration might work well too.
But certainly, if you did all those things it still wouldn't be XP without the pair programming and the on-site customer. But that's okay.
Re:Probably not a good match (Score:2)
Yes, test-driven development should work OK with a distributed team. I'm not so sure about refactoring. Refactoring is changing the design, and it's the practice that lets hard-core XP-ers get away without doing detailed design.
But if single programmers can do unlimited refactoring, where are you? With XP you have your pair-programming buddy to keep you in check; to stop you from making changes that shouldn't be made. But who's going to keep that lone guy in Sweden from messing up the structure?
Colle
Not at all true (Score:2)
Now what that means is that pretty much by definition an OS project usually has the features that make the "customer" quite happy. The variety of UI quality has nothing to do with there being no customer, it has to do with the "customer" feeling too comfortable with how the features
XP worked for us (Score:2, Informative)
The first thing I did were to picture the whole system as a group of functional boxes with interfaces. The next were to de
Re:XP worked for us (Score:2)
Thanks for being honest about this; so many people say, "We're doing XP!" while leaving those things out.
When you get the chance, try them. Their contribution to quality is immense. Once a team gets good at pair programming and automated testing, bug rates can get below 1 per month.
That improves things dramatically. Because you spend less time on
You're all too focused on Pair Programming... (Score:1)
Ways OSS and XP mesh very well: Simple Design, Refactoring, Continuous Integration, Collective Ownership, Small Releases, a Sustainable Pace, and Coding Standards. These are things that most successful OSS projects do, and they're pillars of XP.
However, OSS misses the others, like Test Driven Developmen
Re:You're all too focused on Pair Programming... (Score:1)
Actually, several projects use test-driven design. It's popular in the Perl and Ruby communities, and projects like Subversion and Neon do it too.
Twisted (Score:2)
The problem is that, generally, pair programming is not really possible for most OSS projects, where developers are spread across the globe & communicating by the net. They've been kicking aroudn the idea of a networked multi-user text editor tho..
Programming in pairs (Score:1)
first option: your old school buddy, roughly same programming knowledge and project experience like you joins you in an XP project. You hang around for hours, drink a beer with him, tell dozens of old stories... and then you get productive. Damn productive. XP _might_ work great in these condition