The much hyped Extreme Programming, a form of an agile software development methodology can be a failure in the corporate enterprise. Do you think so? Yeah, I do. XP, like other paradigms has its not-so-good aspects. In XP, detailed specifications or requirement are not created or preserved, so where are you going to run to when a new batch of developers come in, when there is a high people turnover? XP says that developers work in pairs, this aspect really sucks. There is no better person to accompany you in programming and unit testing than you alone. After you develop, you can pass your code to a QA tester for audit and further testing, nothing can be simpler and effective than that. There is no design phase. Most of the design activity takes place while in the development phase, on the fly and evolved accordingly, starting with simplest artifacts to the and adding incremental complexity as the project progresses. The constant refactoring could be a major stumbling block to the cause and this could result in more effort for re-design and re-development. What a waste of time. A representative of the client is also attached to the project. This client rep can become a single-point-of-failure and/or a bottleneck. Why is there a need for a client rep, because, there is no specifications at first hand. Yeah, XP could be very beneficial for small projects but for large, mission-critical ones, I guess the answer is no.
Call me a stereotypical corporate developer but nope, XP is not for me... well, at least I won't advocate it.
3 comments:
You've acquired a very narrow and inaccurate view of XP.
"detailed specifications or requirement are not created or preserved" - yes, they are. They are preserved in the form of executable acceptance tests, at the very least; these acceptance tests are as readable as you care to make them. Being executable, it is easy to determine if they are working or not.
"so where are you going to run to when a new batch of developers come in, when there is a high people turnover?" - Firstly, high personnel turnover is a symptom of an unhealthy organisation. Secondly, the tests and the knowledge of the team members (particularly with pairing) covers this very well in practice.
"XP says that developers work in pairs, this aspect really sucks." - No, it doesn't. Really. Pairing is actually a very exhilarating experience that results in better quality product faster.
"After you develop, you can pass your code to a QA tester for audit and further testing, nothing can be simpler and effective than that." - Except having the audit and testing done as part of the development, thus getting rapid feedback.
"There is no design phase" - That is not true. XP requires developers to have sufficient understanding of the problem in order to estimate. If there are major design uncertainties, then XP recommends spiking as you go; these spikes are pure design and research periods.
Designs to complex problems can not be proven on paper; "boxes and arrows don't crash", after all. You need to be able to verify a design in code as you build it, otherwise you will find yourself walking up the garden path only to realise it's a dead end. That's the real waste of time.
Can evolutionary design screw up? Yes, it can. However, the "constant refactoring" produces flexible code; when design screws up occur, it's usually fairly simple to change direction as required.
"A representative of the client is also attached to the project. This client rep can become a single-point-of-failure and/or a bottleneck. Why is there a need for a client rep, because, there is no specifications at first hand." The client rep can become a single-point-of-failure, it there's only one. XP never states that the "customer" is one person, for that very reason. Why do you need a customer? The customer is the person who can interpret the specifications and communicate them. Rather than having developers attempting to understand a spec (with the inevitable misunderstanding), the customer rep, with a lot more domain knowledge, is on hand to translate in person, correcting the communication errors immediately (rather than six months down the track).
For large mission-critical projects, if you don't adopt an Agile approach (be it XP or one of the other Agile methodologies), then you're setting up an acceptable way to fail. For myself, I prefer to set up a way to succeed, be it acceptable or otherwise.
You're so poorly resistent to change that you seems to me like a corporate bastard.
Thanks for the wonderful insights. Though I don't advocate XP, it doesn't mean that my org does not adopt a form of Agile development approach. In our company, projects are mission critical and mistakes is almost instantlly will cost cash. The scale of such efforts demands many resources as well as non-colocated dev centers, hence, the need for an Agile methodology.
Though I know that XP's approach has good goals, but I stick to my belief for mission critical, larger than-the-norm project, XP can also be dangerous. Otherwise, my org would have adopted XP for a long time now.
Yes, I belong to a corporate environment but I am personally in touch with much of the deltas of our industry. Not such a corporate bastard as our anonymous revolution junkie friend has perceived. Anyways, I believe that not all aspects of any development methodology can and will be adopted by any company. There is always something unique with each one and hence the need to "localize". Readilly going with trends and hypes is as dangerous as not adopting the whispers of required change.
XP is good, no doubt. But in the nature and culture in my org, we cannot and I cannot recommend the use of XP.
Post a Comment