XP Model

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Mike,

      Is the eXtreme Programming (XP) methodology used a lot currently in game development? I just read an article about it in June, 2003 IEEE Software journal and it seems to be a very smart methodology, especially since it takes the software developers sanity into consideration (such as sleep and personal life). It practices a test-driven development (TDD) method designed to delight the customer by providing frequent versions of various specificiation the customer wishes to have present and allowing him to actually play with them instead of just seeing them on the requirements documents. This allows much more direct feedback. It seems that the whole methodology greatly promotes communication between the team, but only of a few minutes at a time. I wonder if this is ever employed in practice as I often here stories of how a programmer goes into his cubicle with headphones on and doesn't take them off until he leaves many hours later and many Jolts later.

      If you would like to read the article here is the reference:

      Laurie Williams, The XP programmer: The few-minutes programmer, IEEE Software, vol. 20, 3, 2003, pp.16-20.

      Nos
    • Good question, I also only heard about XP earlier this year after visiting the web page of, as far as I know, the only game programming company in Perth (where I live). bungarra.com/company.html

      I dunno how well it would work though, I'd imagine that any gain made by the 2 ppl to one machine method wouldn't come close to the amount of time you loose. But I haven't tried it, at least not officially, so I wouldn't know.

      I'll be interested to hear Mike's response.
    • RE: XP Model

      I've tried bits and pieces of XP, but not in on games. I really like it. Over the years I've often paired up with a coworker to solve a particular problem, and it's amazing how easy it is to spot bugs and solve problems when you're back seat driving. ;) I recommend trying it even informally if you can.
    • I have done a verson of XP programming, i never knew it had been classifyed as anything... Me and my friend useually have to share one computer anyways, and useually what it consists of is we try to write out an idea on paper then put it to the screen. It seems to work well, while one person is typing, the other just kinda proofreads or is thinking about alternate ways... It works, i can't say if it as efficant as using seperate computers...
      Wort wort wort.
    • Originally posted by Nostrademous
      I was under the impression that the team of two to a computer is just one option, not necessarily true for all XP methods.


      Here's where I read about it, but I can't really remember what it said so you could be right.

      xprogramming.com/xpmag/whatisxp.htm

      The post was edited 1 time, last by Gerry ().

    • one aspect of XP I forgot to mention is "Test First Design"

      I'm *completely* sold on it 8) I've always been a fan of unit testing, and this approach guarantees they get written. And I'm basically a hacker at heart so I get to write some quick and dirty code (the test harness) up front and get it out of my system :P

      My bug count went down dramatically when I started doing this. There's a good summary of it at xprogramming.com
    • Originally posted by Nostrademous
      I was under the impression that the team of two to a computer is just one option, not necessarily true for all XP methods.


      I just went back and read and it says:

      "Pair Programming
      All production software in XP is built by two programmers, sitting side by side, at the same machine. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code."

      Doesn't sound like the XP dicipline gives you the choice.
    • I'll just go ahead and say it - I'm very cautious about pair programming, as it is defined by "one programming task, two programmers, one computer, 100% of the time."

      This doesn't mean that I support solo programming on a non-trivial project. You should work closely with other programmers, and often.

      I've found that once the main designs for a system are thought through, there's a lot of typing to do, and I doubt very much that two programmers should sit there and attempt it. Have you ever watched someone play a video game and know the solution for a puzzle they're stuck on? "Go left...no your other LEFT YOU MORON!!!!!"

      On the other hand, when you get stuck, the first thing you should do is find another programmer and have them look over your shoulder. That's the best use of pair programming - and I'm pretty sure I've read the same advice somewhere.....

      The problem with the "interrupt" approach is that it takes someone about 30 minutes to get into a good programming groove, and when you bug them because you forgot how to code a linked list in STL you've just nuked their productivity for half an hour. Still - you hope that the result is a higher task completion from everyone involved. It also helps to hire programmers that have good skills.

      Sometimes I wonder if some of these newer programming practices come from the difficulty in monitoring another programmers progress, and when someone is looking over your shoulder you are a hell of a lot less likely to surf the web. Let's face it, there's a lot of that that goes on in any programming shop.

      I don't know of anyone in the games industry using XP, or pair programming, but it is certainly talked about.
      Mr.Mike
      Author, Programmer, Brewer, Patriot