Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
News

Inside the World of Extreme Programming 30

Posted by Hemos from the under-the-hood dept.
Webi writes ""XP[http://www.extremeprogramming.org/] works best for medium-sized teams where a product can be delivered in stages, and where there's freedom to experiment with some of the more controversial techniques," author Ron Jeffries said. http://www.newsfactor.com/perl/story/20348.html"
This discussion has been archived. No new comments can be posted.

Inside the World of Extreme Programming More

Inside the World of Extreme Programming

Comments Filter:

  • Correct link.. (Score:2, Informative)

    by Anonymous Coward
    is http://www.extremeprogramming.org/ of course

  • Buddy Programming kind of annoying (Score:5, Insightful)

    by 0x0d0a ( 568518 ) on Monday January 06, 2003 @08:36AM (#5024709) Journal
    I've always found the whole "buddy programming" concept (part of XP), where one person watches the other code and points out errors, to be incredibly annoying. Maybe you're going to fix something in five seconds (a typo), and it gets called out. Maybe you have a syntax error that the compiler (which isn't getting a salary) could easily catch, but it gets called out. Plus, it makes me nervous to have people watching me and constantly interrupting my flow.

    Also, you're wasting a good programmer having them sit there and call things out.

    Maybe it's just me and some people really like XP...

    • It is when you do it wrong (Score:5, Insightful)

      by Anonymous Coward on Monday January 06, 2003 @08:56AM (#5024803)
      The 'buddy' isn't supposed to second guess you or the compiler, they are supposed to think strategically while you think at a tactical level.

      Switching thinking modes is incredibly difficult to do by yourself but imagine your 'buddy' as 20/20 hindsight in advance. Remember: a stitch in time saves nine.

      Oh and if the 'buddy' has something tactical to offer (i.e. code) then give him the keyboard and take a step back (mentally, of course).
      • The 'buddy' isn't supposed to second guess you or the compiler, they are supposed to think strategically while you think at a tactical level.

        Hmm...but shouldn't that have been done when APIs and rough data structures were decided upon?
        • Hmm...but shouldn't that have been done when APIs and rough data structures were decided upon?

          In XP, that is exactly when the APIs and rough data structures are to be decided upon: when the need arises. That's why you have a pair: to help you design as you go. If programming consisted solely of typing, you wouldn't need a pair.

          (And why do the design when you need it instead of at the beginning? Because design is too important to do at the beginning when you don't know exactly what you need or how it's going to fit with existing code.)

          • ...design as you go.

            From what I've seen, design-as-you-go is very very dangerous when average programmers are doing the work.

            Even Extreme Programming does not remove the dependency of needing a super-star on the team. No design or programming philosophy does. This is why such philosophies are for informational purposes only--no real project should actually be based upon one of them.

            • Even Extreme Programming does not remove the dependency of needing a super-star on the team.

              I think you are right about XP depending on having a good team. The fundamental idea in XP is to make software more change friendly (automatic testing, refactoring, collective code ownership, pair programming), and this in turn allows design-as-you-go to be an efficient practice. The reason that up-front design is traditionally considered so valuable is that the cost of changing software seems to grow very fast during the project. If the cost of change is lower it might become feasible to design as you go instead.

              Since I haven't tried XP in any real project, I can't claim I know it would work in practice but the idea is very interesting. Since XP might be a little too extreme (that's why it's called eXtreme Programming) there are other methodologies that are philosophically similar but less demanding (so called Agile methodologies) that one might try instead.

    • Pair programming (Score:4, Informative)

      by Lumpish Scholar ( 17107 ) on Monday January 06, 2003 @09:40AM (#5025054) Homepage Journal
      I've always found the whole "buddy programming" concept (part of XP), where one person watches the other code and points out errors, to be incredibly annoying.... you're wasting a good programmer having them sit there and call things out
      Right, that would be dumb; but that's not what XP calls for.

      Pair programming [extremeprogramming.org] calls for two people working together. At any given instant, only one person has the keyboard and mouse; but they get passed back and forth, and the person who's not typing is doing a lot more than "watching." It's as natural as two people designing together on a blackboard, once you get the hang of it.

      Does it work? There's lots of evidence it's worked for a lot of people who've tried it (including me).

      Does it always work, for everyone, in every project? That's an open question. The only way it'll be answered is if more people try to program in pairs.

      The definitive book on the subject is Pair Programming Illuminated by Laurie Williams and Robert Kessler (Amazon.com [amazon.com], BN.com [barnesandnoble.com]); recommended.

      Pair programming is not the first XP practice a project should try. Could a project get a lot of value out of XP without doing pair programming? I think yes, and I'm an advocate of programming in pairs; the question is open to debate.
      • Does it always work, for everyone, in every project?

        I'd say no. I know many programmers who don't have the skills or desire to work in teams (pairs or larger teams). This is understandable, because a lot of people who got into computers as a hobby enjoy spending time by themselves.

        I'm one of those people, but I realize that teamwork is essential to a project's success, so I do my best to be social and work well with others, though it's sometimes hard and drains my energy.

        But there are some people who won't (or can't) work with others. These are the people who I think won't be good at pair programming (or working with a team in general).

      • Pair programming does not merely increase quality of the output code, it is a fantastic way to perform knowledge transfer (either of specific code design, or general coding skills, depending on the relative skill level of those involved).
        Does it work? There's lots of evidence it's worked for a lot of people who've tried it (including me).
        Chalk up one more piece of anecdotal evidence -- I've done it, and I recommend it.
        Does it always work, for everyone, in every project? That's an open question.
        I have some doubt as to a theory that any one methodology can be a panacea. (This is why we have great holy wars [tuxedo.org] over things like editors [vim.org]...)
        Pair programming is not the first XP practice a project should try. Could a project get a lot of value out of XP without doing pair programming? I think yes, and I'm an advocate of programming in pairs; the question is open to debate.
        Hear, hear. There are several standalone XP practices [extremeprogramming.org]: code-to-the-test, pair programming, e.g. I recommend giving those a try first. If you can find an XP advocate with some experience, having them walk you through some of them has to be the best way to go about it. (IMHO).
    • I used to do this all the time when I was pair programming with someone, but I got to waiting til he finished the line or sometimes the entire function. If it's on my mind "hey he made a typo" and bugging me that the function's not going to work because of it, then I can't very well discuss tactics.

      It helped that he was already a good friend. I think more realistically, one person should get the keyboard and screen and another should get the whiteboard. Both should be chatting continuously. Looking over your buddy's shoulder is going overboard IMHO.

      Overall, I think the main benefit to pair programming is that it puts the programmer in the position of having human contact through the day, which helps them articulate issues to managers and customers. Even if you're not a completel socially stunted nerd, going without talking to people day after day will really warp your thinking in ways that make you hard to deal with.

  • Re: (Score:2, Insightful)

    by account_deleted ( 4530225 )
    Comment removed based on user account deletion

  • the weakest link in XP (Score:5, Insightful)

    by josephgrossberg ( 67732 ) on Monday January 06, 2003 @09:05AM (#5024863) Homepage Journal
    Is the degree of customer involvement that they expect.

    To quote their site [extremeprogramming.org]:
    "One of the few requirements of extreme programming (XP) is to have the customer ... be a part of [the development team]. All phases of an XP project require communication with the customer, preferably face to face, on site. It's best to simply assign one or more customers to the development team."

    WTF? How many clients are willing to assign an employee to work with/at the software/website vendor full-time? None, in my experience.

    Unless you're dealing with an utterly massive project for a heavily-staffed client, their IT guy leading this effort has more responsibilities than this one project.
    • I agree; which explains why XP customers are almost all developers themselves.... ;)
    • If the customer is not willing to commit (somebody's) significant time to the project, it's pretty much a dead horse, waiting to fall. If the customer is not , at the least, completely involved in defining the requirements and the acceptance tests the final product will not be what the customer wants. Period. It might be what you have on record as what the customer asked for, but it will never "fly" for simple lack of interest, and you will have no follow-on work. If you are not serving the customer, you will not have a customer. This has been my experience, anyway. (Perhaps you have been luckier. If so, don't count on it to stay that way. Lots of out-of-work developers out there.) ttfn
    • Is the degree of customer involvement that they expect.... How many clients are willing to assign an employee to work with/at the software/website vendor full-time?
      It makes more sense for in-house development projects, where the "customer" already has an office in the building, and just reports to the programming bullpen* rather than to his/her own office/cube/whatever. The first serious XP development effort was an in-house project called Chrysler Comprehensive Compensation; the "customer" was the payroll department, and relatively easy to get "on site." XP has been strongly influenced by the patterns from that project.

      *A lot of XP gurus like open space plans for development teams. YMMV.

      The most common alternative to Customer On Site [extremeprogramming.org] is Victorian Novel Requirements: the customers write hundreds (thousands) of pages of requirements (which can take as many staff hours as Customer On Site), throw the book "over the wall" to the development staff, and then complain when they didn't want what they originally asked for.

      I agree Customer On Site may not always work. Lots of constant communications with the customer, in some form or another, is necessary for any successful software project, XP or otherwise.
      • Let me clarify: I'm not saying that "Customer On Site" is a Bad Thing. I think it'd help the developers a lot, by cutting down on guesswork and time spend "waiting for feedback/approval" (assuming that the one person on site is thoroughly knowledgeable(sp?) about the problem domain, is a good communicator and has authority to make decisions/tradeoffs).

        I'm just saying it seems pie-in-the-sky unrealistic. Moreso than the much-maligned pair programming (which I also think is written off too soon), because you need *two* bosses to sign off on it: the developers' and the on-site customer's.
    • WTF? How many clients are willing to assign an employee to work with/at the software/website vendor full-time? None, in my experience.

      No probably not. Most are quite happy spending months trying to get so-called bespoke software doing what they want instead of what they asked for.

      On the other hand, they are perfectly happy to pay for the privilege of beta test shrinkwrapped code. Go figure.
  • This might sound trivial, but one of the obstacles that I've found to buddy programming is the simple question of access to the machine. Inevitably in our space somebody gets to 'drive' and somebody else has to pull up a chair. If the driver wants to hand off the keyboard to his buddy, then the buddy will stretch and suffer and type poorly with the keyboard in his lap until it becomes obvious that he has alot to type, at which point he'll say "Can I drive?" and they switch seats. It's even worse when it comes to the mouse, since often you can't reach both without getting into your buddy's face as you reach across so you'll end up telling him "Ok, go click here..." which isn't exactly the best use of either geek's time.

    If somebody could tell me a way of optimizing this exchange, I'd love it. Simply getting big lab space isn't really an option -- in the one lab we do have the tables are so small that you can't even fit the keyboard in front of the monitor and often end up with it next to, or in your lap anyway.

    • keyboard/mouse switch?
    • If somebody could tell me a way of optimizing this exchange, I'd love it.

      How about having two keyboards and two mice? (I assume PCs can handle that; I've only ever tried it on a Mac.)

      But I've never had much of a problem. The chairs have wheels; you each slide over so the other person is sitting in front of the computer. When you switch back, you both slide the other way.

    • Re:Driver's Seat (Score:4, Funny)

      by phamlen ( 304054 ) <phamlen AT mail DOT com> on Monday January 06, 2003 @11:40AM (#5025887) Homepage
      It's definitely not trivial - it's one of the reasons that people continually mention how to arrange office space to help XP.

      We put the computers on a wide table in the center with enough space for two people to sit. When someone wants to switch, the other person slides to the side.

      The other key element is to provide breath mints at every station.My personal belief is that pair programming is best done when there's enough space and breath mints for everyone involved. :)

    • VNC...

      at least under linux, VNC is quick enough to make it better than shoving the keyboard back and forth. You have to work out the signals within the pair so you don't 'stomp' on each other.

      Under windoze... VNC is less useful.

      As for getting the furniture you need... if you're lab isn't set up to do pair programming, then you cannot effectively do pair programming. Then again, I've done useful pair programming under windoze using VNC over a T1 with a headset phone... It's better than nothing.
      • Under windoze... VNC is less useful.
        I dunno, worked for me. I'm assuming you're talking about using a Windows VNC server when you say "Under windoze". I'd probably agree that there's more latency using a Windows VNC server. If you're not limited to Windows-only IDEs/compilers, then you're free to develop on a unix platform (which hosts the VNC server), and use win32 VNC viewers.
    • You could put two pc's next to each other and just use the same desktop (vnc or whatever).

      Also another very very cool thing is if you use emacs you can open the same window on another machine. Then you can see each others changes in realtime, and both modify the file at the same time. What is even cooler is that you can view and edit different parts of the same file. This has the advantage of say vnc because one could be coding while the other fixes spelling mistakes, adds comments, and does the higher level thinking. (I tend to associate the commenting and higher level thinking together - correct me if I'm wrong)

    • Isn't it good for you to stretch every now and then? When we do the pair programming thing.. we usually do about 45min each, then swap chairs. Sometimes the person who was typing goes to get candy..:)

  • Dilbert? (Score:2, Funny)

    by batemanm ( 534197 )
    Would this [dilbert.com] be proof that Scott Adams reads slashdot?

Slashdot Top Deals

Make sure your code does nothing gracefully.

Close