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

8 of 60 comments (clear)

  1. XP in college by lambent · · Score: 4, Interesting

    We tried XP approaches in my college programming classes. More often than not, it caused my partners and I to claw each others' eyes out, and generally despise your partner for the remainder of the project.

    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.

    1. Re:XP in college by Anonymous Coward · · 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.

    2. Re:XP in college by Jerf · · Score: 1, 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.

      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 programmer, you need to be expanding your horizon past school assignments, even now. I'm not far out of college but even when I was in it I was doing extra things that revealed how miserably that design methodology worked.

      (Heck, I even had homework assignments large enough to reveal how that doesn't work; YMMV.)

      You might want to hold off on the design prognostication; if you're in college, odds are you're promoting a design approach that has been obsolete since before you were born. I'd be a little embarrased about such things, especially in this industry.

    3. Re:XP in college by Anonymous Coward · · Score: 1, Interesting

      I really like XP, but I wouldn't recommend trying it unless you have someone there to mentor you who has used it before. Some of the practices of XP rely on others. If you try to ignore one, the others fail as well.

      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 at the big picture. From that point of view, there really isn't much need for that person to be looking at the screen. When I'm not typing, I have a tendency to get up, write on the white board or sit in a position where I can't see the screen. It helps me focus on the design and the business rules rather than style and punctuation. You have to stay close, however, because peer-review is part of the advantage to pair programming.

  2. didn't chromatic have an article on this? by Anonymous Coward · · Score: 5, Interesting

    I remember reading an article on O'Reilly about XP and Open Source .. go dig it up..

    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.

    1. Re:didn't chromatic have an article on this? by Corfitz · · Score: 3, Interesting
      Maybe you're referring to this piece on "Five Lessons Open Source Developers Should Learn from Extreme Programming".

      Well worth the read

  3. Doesn't seem suited for OSS by wayne606 · · Score: 5, Interesting

    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. Also it is good for making a larger number of so-so programmers as productive as a few really good programmers.

    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!

  4. Can't see... by smari · · Score: 4, Interesting

    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.
    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.