Slashdot Mirror
Inside the World of Extreme Programming
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"
XHTMLC (eXtreme HTML Coding) might have saved us from that mistake.
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...
May we never see th
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).
Is the degree of customer involvement that they expect.
... 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."
To quote their site:
"One of the few requirements of extreme programming (XP) is to have the customer
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.
Joe
http://www.joegrossberg.com
Pair programming 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, BN.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.
Stupid job ads, weird spam, occasional insight at
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.