Xtreme Programming is a seriously flawed technique. As development methodology XP is nothing new. Iterative development was first explained by Spiral model which was introduced back in 1986. Also, few of its basic rules, most notably Peer Programming and Collective Ownership, are really against the management sense.
Peer programming simply wastes a resource. One guy writing the code and other just watching him write the code is just non-sense. Why not let both of them write their own code and review each-other's code at the end of the day? It is also very difficult to pair the right programmers together as not all programmers are made equal. So if you pair a good programmer with a not-so-good-programmer then the results will suffer, the productivity of the pair will be lesser than the productivity of the good programmer working alone as he will need to explain him self quite frequently. Programming is not an exact science. Its an art and programmers, like musicians, painters, writers, work well when left alone. You wouldn't want Picasso and Michael Angelo working on the same painting, would you?
Collective ownership diminishes the individual sense of ownership and responsibility. For a highly productive work environment, it is important to develop sense of ownership in the work force. As employees (developers in our case) develop sense of ownership there is an increased sense of pride, motivation and self-esteem. This results in increased productivity. If you want great software, let the developers own what they create.
In my opinion, XP is overrated and unpractical. Some of its ideas like Test First Development, Refactoring and Integrate Often work well but they are not specific to XP. Others like Pair Programming and Collective Ownership really make no sense.
8 comments:
Really have to disagree with both points. An average programmer does not write code for more than 4 hours a day (certainly applies to me, except when some deadline is looming). Pair programming is actually more productive in this sense. Also, indivisual code ownership usually gives too much power into the hands of one person. Collective ownership mitigates risks.
Well, I write code almost 8 hrs a day. When I am not writing I am thinking about the problem. As I said not all programmers are made equal :) Still not sure how it relates to Pair Programming.
and there is no individual ownership. A single programmers only owns a part of the software and that is no way dangerous.
I dont think giving ownership of a partial piece of code is a big issue, but in my opinion, what is a big issue is that, when it comes to extending code for further development or re factoring that code, results of collective ownership are far superior.
so in the long run I believe collective ownership has merits.
XP as a way of implementing collective ownership might be debatable.
Besides, as far as code & solution research is concerned that is done individually, but, when it is time to actually write code, that is done collectively i.e. in a pair. so your argument that time is wasted reduces here by at-least 33% to 50%.
Common errors which happen due to lack of concentration or coder fatigue are avoided in pair programming, also debugging time is reduced greatly as well.
Your argument that its not easy to match programmers for a pair hold merit. but then again it is subjective. I always pair up a senior and a junior programmer, it helps increase the junior's capabilities and junior programmer's input helps in overall development.
I dont know about picasso and michealangelo working on a same piece .... but if they ever made a classic master piece together, wouldn't it be wonderful :) !!!!
I think you ppl are missing the point here. My point is that peer review will give you same advantages as pair programming i.e better code quality and less errors, while avoiding the draw backs. I would like to quote Donald Knuth here:
I also hate to offend other people’s sensibilities—given that software methodology has always been akin to religion. With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term "extreme programming" sounds like exactly the wrong way to go...with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me.
What you are missing is we are arguing against your hypothesis 'Extreme programming is overrated'.
Extreme programing doesn't claim that its a panacea to all your software problems. It just points out a few techniques that can help you develop a better software.
As far as peer review is concerned, in my humble opinion, if during peer review you will analyze the code as throughly as you would do during peer programming then it would take relatively longer time to develop the product ( because you will be correcting the design at a later stage).
And of course who can refute Knuth.
"working in teams and reading each other’s code. "
Are these two things not the very problems that you identified with XP.
I know he doesn't mean peer programming when he says working in teams but this is the extreme case when working in teams. And as I mentioned in my previous post that the idea is that you correct the mistakes at the earliest stage and someone should have a good idea of the code when a programmer leaves the company.
For the record: I repeat 'Nothing is absolute, either good or bad'
Well, it looks like we have different idea of what "working in teams" means.
And no these two things are not the problems that I identified with XP, I am saying that XPs version of these two things i.e Pair Programming is the problem. Reading eachother's code and working in team is important but not they way XP wants us to.
The last company I was working in was pretty relaxed on the programming paradigm we used, so we could experiment a lot. The best process that we came up with was a form of loose pair programming.
Two guys would sit together with their individual notebooks. The navigator other would work on the design documents, write stub code, come up and run the unit tests, run searches and write comment. The driver would be doing the actual codding. We would ofcourse switch responsibilities after a while (after a coffee break). The technique worked pretty well. Average programmers like me could reach the productivity levels of rock star programmers like Adnan. Whats more, the code written like this would almost always pass QA without an issue and it was always better documented than the rock star’s code.
Pair programming is built on the ages old principal that two heads are better than one. It works.
Post a Comment