| XP
- Pair programming? Note: This entry was written last year, but, I didn't get around to post it until today: August 29, 2004.  've been
doing some research on eXtreme Programming, for I have to give a presentation
(class project) in one of my Software Engineering classes and I have a
couple of comments I thought were worth a whole page in my web site.Bad name for a methodology From a Software Engineer's perspective, I could care less what a methodology is called. However, I think the name of eXtreme Programming for a development methodology, was a badly chosen name (No offense to the inventors/creators, this is only my personal opinion). The name connotes programming only - And not just programming, but eXtreme programming. I have to admit that the first time I heard the term, the image that came to my mind was of a programmer coding a bayesian SPAM filter while doing 360s on a mountain bike. I was wrong, oh, so wrong. If you read the fine print, one can eventually dig out that the whole thing is a Software Development methodology (Yes, another one). XP is a whole new methodology to build Software Systems ("new" here is relative - I don't think it's so new any more). XP is part of the new (again, not so new) RAD methodologies and promotes iterative builds, with minimal documentation, and the process expects the end user or stake holder to always be involved throughout the life of the project. XP is not so different from other RAD methodologies, but quite the opposite of the heavy document-oriented Waterfall methodology. Some say that the Waterfall methodology is a no-no methodology to follow now a days, however, most of the projects I've been involved in have a certain waterfall flavour. But, I digress... Pair Programming Although, there is no mountain bike programming, there is programming: pair programming. This is probably the most hard to swallow aspect of the methodology. From a management perspective, you have to wonder if it is really necessary to have 2 programmers working on a specific task, when we have been using only one in the past. The literature claims, however, that two heads work better than one; that the quality of the code increases, as there is a double redundancy check, if you will, by having one developer coding and the other debugging in real time: looking over the shoulder debugging (I should patent the process). I can see the (claimed?) benefits of coding in pairs, but, it would get really boring very quickly. Well, at least I would get bored. The main reason some of us become Software Engineers is to be creative and invent something that hasn't been invented before. I think of the act of engineering software as an art, mixed with a bit science. The art comes in the stile of each developer, and the science comes from the fundamentals of computer science that we all share: algorithm design, design patterns, etc. With different stiles for each developer, you can imagine the problems an XP project must deal with from the beginning. Who codes and who watches? How do you pair the developers? Which coding stile to use: yours or mine? What if only one developer is doing all the thinking? Should I get a mountain bike, to call it real eXtreme Programming? I shouldn't say XP would stop creativity while developing software. I think XP would still allow developers to be creative, however, there is a conforming phenomenon, as one programmer could just accept certain things from the other programmer so that no feelings are hurt. Or just arguing about little things, would just be exhausting. Some of the issues go away, if the paired programmers have the same expectations and have similar experience. But, how do you know how to pair the developers? I haven't done it I haven't worked in an XP driven project and I wouldn't dismiss the opportunity of working in one, if offered to me. I mean, the more tools under my belt, the better and I'm willing to try different methodologies, at least once. People have used eXtreme Programming in the professional world, and there are testimonials you can read around. In the end, it's really up to each Software Developer Manager to assess the success or failure for each project. I'm sure, though, that when it comes to XP we hear of the more successful projects and not the failed ones. Surprising though, as the failure rate of software projects varies from 70% to 80%, according to the expert of the year. It seems to be an awfully high rate of failure, but we've been discussing this issue since the late 1960s. Does XP help solve the problem? Some claim, yes: the inventors of XP. Would you use XP for your projects? And most importantly "pair programming" for a long period of time? |
 |
|
| Guestbook | Copyright ©
Jose Sandoval 2005 - jose@josesandoval.com |