Jump to content

Extreme Programming


gobbledonk

Recommended Posts

Apologies to those who arent from an IT background, but this section seems to get more IT people than any of the others.

 

My new job is pretty damn good so far, but one of the things I am a little concerned about is that we are moving to Extreme Programming, an approach which is proving increasingly popular among development teams which are brave (crazy ?) enough to break out of the mould and try something new.

 

On paper, it looks great : write the tests before you write the code, iterative releases, refactoring and continuous integration : all great stuff. My concern is pair programming. Whilst I have worked on designs and code with someone looking over my shoulder before, I have never sat down and attempted to solve an entire problem collaboratively. I'm interested in hearing feedback from anyone who has - what were the pluses ? Does it live up to expectations ? Did you strike human-not-machine problems etc ? What happens when one half is having an 'off' day and the other is pumped full of caffeine, for example ?

 

Thanks in advance.

Link to comment
Share on other sites

  • Replies 34
  • Created
  • Last Reply

My, my - for a supposedly new, technology-driven industry, programmers are surprisingly conservative creatures, aren't they? I don't think there's anything to be afraid of. I started to read about it on http://www.extremeprogramming.org/ last year (but still haven't had the chance to put it into practice). I'd be one of those people who usually work alone but the idea of pairs programming intrigues me. Haven't you ever come across at someone's solution to a problem that you thought could be better than yours? It'd be surprising if you hadn't. Even within one language, people have slightly different skills, experiences and biases. Why not take advantage of that?

 

As for the human problems, are you really saying you simply can't work them out? I've seen some case studies where people were saying that pairs programming was, to their surprise, the best thing that came out of XP, that it improved their skills and the quality of code and furthermore, that things were actually agreed quite easily. Some days one person'd take more of a backseat and sometimes not. Some pairs complemented each other better than others, of course, and they tried switching around to find the best ones. But overall, they found that discussing each others programming ideas in pairs was a much better, friendlier idea than code review by peers. People were much less defensive that way. It was usually apparent and readily agreeable whose idea for a certain task was better.

 

So, overall, I like the idea! I just don't want to be paired with a dumbo, that's all... :neener:

Link to comment
Share on other sites

I tried this with some of my programmers as an experiment a while ago and the feedback was favourable. This may have been because participation was voluntary and so only those favourable to the idea took part. As far as I was concerned, first time code quality improved but was no better than our normal code - peer review methods.

 

Interestingly, in spite of the positive feedback, no-one has asked to repeat the experiment !

Link to comment
Share on other sites

Bibblies,

 

So, overall, I like the idea! I just don't want to be paired with a dumbo, that's all

 

Thanks for your input, Bibblies, but I think you've hit the nail on the head re a possible downside to the whole thing : differing skill levels. Ideally, you would pair a wise, patient veteran with a relative novice for two days a week, then allow the more experienced guys to work together to thrash out a tough module, and so on.

 

The issue, as I see it, is the 'me' factor. Pair programming requires an acceptance on the part of the more experienced professionals that mentoring is a major part of his/her role, and that you have to put aside your ego and work with someone who may not be on the same level as you in terms of either programming or knowledge of the domain in which you are working. Some people will simply never be ready to accept this, and I know even know programmers who dont want anyone to reuse 'their' code - tragic.

 

Disagreements between two more experienced programmers are another area which I would consider a potential downside. I see enough of this in code reviews, and its often necessary for a 3rd party to be able to say - 'Hey, you're BOTH right, just put down the carving knives !'.

 

I also have a recurring nightmare about having to program with someone who has an inflated view of their own abilities : the know-it-all. Spending an hour or so arguing with some clown over the 3 lines of code we've actually managed to write isnt my idea of a good time.

 

The pluses, tho, are undeniable. Imagine being able to debug a colleague's code without thinking 'Jesus, what was he trying to do here ?'. I'm a big fan of '3 lines of simple code beats a single line of obfuscated hierolyphics', but its difficult to convince others of that when everyone is left to write their own code (Perl lends itself to those who dont want others to understand their code...). Code reviews help, but how much better is it if we can see what we are getting ourselves into as we both layout the code ? Definitely a plus.

 

OK - enough prognostication. I shall report back after I've gained some real-world experience. Happy trails, fellow code cutters !

Link to comment
Share on other sites

Hi!

 

This sound rather similar to a development model used by a large Swedish telocom manufacturer. Large projects can involve the development of many million lines of code. The only possibillity to pull this off is to work in large teams. Tha largest project I worked in had ~800 project members of which at least 200 were software engineers.

 

Personally I find it interesting to work in groups but of course some individual happy hacking can be fun to. :grinyes:

 

regards

 

ALHOLK

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...