Vikram Goyal's Blog

Off the XP bandwagon

For some time now I went on the Agile programming bandwagon convinced that it was the next best thing since sliced bread. After a sustained year of practicing it, I am off the wagon. It is annoying, superficial and doesn't necessarily produce better results than traditional programming.

My problems with Agile programming.

-- Without a design up front, you are shooting in the dark hoping that what you are doing now will retrofit the final solution. This doesn't work for me. I want to analyze a problem domain to death before I commit any time to it. Traditional programming methods don't preclude the idea of a prototype to test your designs and neither do they disallow changes.

-- The last thing that I want is for another developer sitting with me and criticizing my code, while I am writing the code. And no, I don't want to do the same to him. It leads to friction, waste of time (two developers working on the same task?), hassle and fuss over finding two developers who will get along with each other and so on. The worst possible idea.

-- Continuous small builds is a great idea. But continuous small builds lead to a nightmare in code management and dependencies. What would have worked yesterday wouldn't work today because somebody else refactored something that has broken the current build cycle. On the other hand if everybody was programming against a well set design there would be less (I say 'less' not 'no') integration issues.

-- Project requirements are always in a flux. This is the central tenet of XP and I find this always-in-the-dark kind of coding irritating.

While your mileage may wary, I am pretty sure that XP is not working for me.

Comments

• What I find interesting, is that every single point you make, boils down to one issue:
  You don't want change. Which is the exact point that XP is trying to make.
  

  Posted by: voorth on October 02, 2005 at 11:01 PM

• Hi voorth,

  Although I disagree that all my issues boil down to me not wanting change (how did you deduce that?), even if that was the case, I am happy to change to a system that benefits me and my projects. Alas, XP didn't offer any such benefits.

  Would you say that a person who tries traditional programming techniques after working in XP and doesn't like it is afraid of the change?

  Vikram

  Posted by: gvix on October 02, 2005 at 11:29 PM

• Change is good, but XP seems to promote change for the sake of change.

  While it has some good ideas I too am skeptical about the applicability towards larger projects especially.

  Posted by: jwenting on October 03, 2005 at 01:21 AM

• Here here. I could not agree more.

  I, too is sceptical on XP. But, ironically, I do like XP, but only in theory as we never had pure XP applied to our dev methodology before. I like it for the promise of managing a fast-paced development effort. One thing I don't like about it, whether I'll be fully converted as an XP fanatic or not, is pair-programming.

  Posted by: richardqr on October 03, 2005 at 02:28 AM

• jwenting,

  You echo my thoughts. XP seems to promote change for the sake of change. I had practical difficulties working with it.

  
  richardqr,

  Yes XP seemed pretty good in theory, but in practice didn't live up to the hype. Pair-Programming seems to be the most hated aspect of XP.

  
  Vikram

  Posted by: gvix on October 03, 2005 at 02:38 AM

• Absence of archictectural design is the major limitation of XP. It confines the approach to very conceptually simple applications; where the team just sort-of 'guesses' at the next steps. I think its current popularity stems from how it is pitched to management: "Software development, without all that engineering stuff."

  It clearly wins hands-down however, in the keystrokes per hour category, which is very important to some managers.

  Posted by: cajo on October 03, 2005 at 03:57 AM

• I totally agree. While some aspects of XP seem to be ok, these are applicable to 'non XP' as required too, such as refactoring caused by changed requirements after spec is ready, etc.

  Posted by: uhilger on October 03, 2005 at 05:15 AM

• Programming 100% in pair and only with the same developer is sure a waste. But programming in pair occasionally (say 10%) and with different developers helps in various ways: speeds up knowledge exchange, reduces bugs by code incpection, sharing of best practicess...
  

  Posted by: mcekovic on October 03, 2005 at 06:21 AM

• I have successfully used XP on a large development effort. Our approach was probably not "pure" XP, but it did work for us (even pair programming).
  The key is remembering that XP is not right for every project. It is a tool that is available when needed. It is not a panacea for all development.

  Posted by: haled on October 03, 2005 at 06:57 AM

• Vikram,
  Are you really off agile development or just wanted to see reaction of people. I think agility is not pair programming, documentation or architecture. It's ability to produce working software that meets customer's demands. You only mentioned some of the practices of XP and though in first edition Kent's view was that if you are not following my 12 practices you are not XP, but he has softened that tone. I actually like to choose my practices and apply what works for me. For example, though I may not choose six month BDUF, but I think good architecture and deep domain model is important, even if it takes several weeks. Would that make me unagile, I don't think because agility is really choosing balance between whatever works for you. Similarly I agree that with good design and deep model, I would less likely to do refactoring. I think refactoring is a step backward and with little time up front on good design, I will do a lot of step backwards which means no progress on actual delivery. I am not big fan of pair programming either, I actually like side-by-side programming advocated by Alistair's Clear Crystal. There are some agile folks who warn about issues with pair programming as well such as unsocial attitude or sexual tensions. Regarding broken continuous build, it only happens if your process is broken meaning someone is checking in code without fully testing or worse without writing tests. I think there might be some disruptions in continuous integration but it saves you days of integration effort at the end of iteration (assuming you are not using shorter iterations). Finally requirement changes: it can be solved with simple rule no requirement changes within an iteration, all changes effect next iterations. Again if you are using small iterations, it will not effect. I read somewhere that with short iterations, you can deliver the software before customer changes their mind so in a way it can probably have worse effect on longer iterations. In nutshell, throw any practices that don't work for you as long as your customers are happy with your software.
  

  Posted by: shahzad on October 03, 2005 at 07:02 AM

• Hi Vikram,
  it looks like your comments are made most from expectations that from first hand experience.
  I may be wrong, but I suppose you did only some small experiments and not one year full time in an xp team.

  Reject BDUF doesn't mean no design, xp is very clear about this point: TDD is about design.

  Your critics about continuos integration completly forgets the full set of automated tests that xp requires.

  And "Project requirements are always in a flux" is a not an XP choice, is a fact for most projects. Most of design choices are made just to accomodate future changes.
  "Requirements always change" is a tenet of software engineering.

  I suggest to follow the xp and tdd mailing list on yahoogroups to better understand what xp is about.

  Bye

  Lorenzo

  Posted by: trz on October 03, 2005 at 07:03 AM

• 
  Hi cajo,
  AFAIK xp is not very well accepted from managers.
  And if you consider pair programming, test code and refactoring you probably have a lower LOC count per person than with "traditional" metodologies.

  Bye

  Lorenzo

  Posted by: trz on October 03, 2005 at 07:08 AM

• I used to share a lot of this scepticism about XP. But XP works the best if you "train" yourself to find a fresh new point of view while looking at the same old problems.

  For example, it is a good thing if someone breaks the build. This exposes a potential issue immediately and is guaranteed a prompt response from the team. Much better than "big bang merge" right before the next release.

  Posted by: mgarber on October 03, 2005 at 07:20 AM

• Learning new things is never a problem, it is unlearning old things that humans find almost impossible.

  The new generation that have grown up with instant messaging and online gaming will find xp a lot more natural than we do.

  I still need to print things out to really study them, younger people can't take in information from paper, they have to scan it in so that they can scroll backwards and forwards....

  Posted by: c_armstrong on October 03, 2005 at 07:37 AM

• great post Vikram. I too have had some of these same issues. Do you think maybe XP works well for stictly coders but for people that have to wear more than one hat it gets in the way?

  Posted by: mmorton8 on October 03, 2005 at 08:44 AM

• "Continuous small builds is a great idea. But continuous small builds lead to a nightmare in code management and dependencies. What would have worked yesterday wouldn't work today because somebody else refactored something that has broken the current build cycle. On the other hand if everybody was programming against a well set design there would be less (I say 'less' not 'no') integration issues."

  1) Well designed APIs change too... same problem (and actually worse since people tend to avoid changing them since they are a pain to fix if you don't have a proper structure in place).
  2) If they refactored they would have had to make sure all the code compiled
  3) the tests make sure the code compiles and they should not be checking in code that breaks the build or the tests...
  4) all that could be broken, assuming #3 above, is what people currently have checked out... but people shouldn't have much going on at once so the break would not be large on their current checkouts... and if the code were checked in then the person doing the refactoring would have fixed it (see #3).
  

  Posted by: darcy on October 03, 2005 at 09:30 AM

• The Tao cannot be passed on by management decree

  Posted by: jhogan on October 03, 2005 at 01:13 PM

• Some great comments here. I am replying in two parts

  Part 1:

  cajo : " team just sort-of 'guesses' at the next steps" is exactly what I was trying to say. It makes me mad that I am working in a vaccum where the next step may or may not be right.

  mcekovic: "But programming in pair occasionally (say 10%) and with different developers". Sure if you have a team large enough to be rotated around. But have you considered the logistical nightmare that this causes? This may sound good in theory, but practically, it's the thing that causes the biggest headache.

  haled: "The key is remembering that XP is not right for every project". Absolutely. And it is not right for every developer. That is what I said at the end of my post. Your mileage may wary about XP. For me, it was a waste of time.

  shahzad: "Are you really off agile development or just wanted to see reaction of people". I am really off agile development and was posting my reaction to it. I will take some positives from it: solid unit testing and constant client interaction spring to mind, but overall, it did not work for me.

  "It's ability to produce working software that meets customer's demands". That stands for traditional practices too. XP or no XP, the goal is to produce working software!

  "I actually like to choose my practices and apply what works for me." Exactly.

  "In nutshell, throw any practices that don't work for you as long as your customers are happy with your software." The goal is to produce software for customers that they are happy with. They don't care what our internal practices are and neither should they. In the end, it really is not about the customer but rather about providing your own team with a better working environment which is more productive. XP didn't do that for me

  Cont next part...
  

  Posted by: gvix on October 03, 2005 at 04:41 PM

• Part 2:

  Lorenzo: I did follow XP for quite some time and read books and tried to apply things in small doses. But it just didn't lead to better productive environment and I guess my disappointment stems from the fact that I had high expectations of it. As I said before, XP is great in theory.

  mgarber: "But XP works the best if you "train" yourself to find a fresh new point of view while looking at the same old problems". Agreed, and this was a big change for me, so I was determined for it to work. But I realized, after an year of working on it and with it, that I didn't like what I was doing because it was leaving me constantly in a state of indecision where I was second guessing myself constantly.

  c_armstrong: "The new generation that have grown up with instant messaging and online gaming will find xp a lot more natural than we do" And I thought that that was me! I grew up with that and it hasn't worked for me. :). But you are right. XP has an uber-geekiness to it that attracts people.

  mmorton8: " Do you think maybe XP works well for stictly coders but for people that have to wear more than one hat it gets in the way?" Great point. I had never thought of it this way. I am not sure that I am a strict coder anymore, so maybe that is why I failed at it.

  darcy: So XP and tranditional programming are similar in this sense. Integration causes a lot of pain. Right? So what is the advantage of using XP here?

  Vikram

  Posted by: gvix on October 03, 2005 at 04:57 PM

• 
  Vikram, I understand what you are saying.

  Up-front design: Would you build/ride an airplane without it?
  Pair-programming: Save your olfactory nerves, use Eclipse with checkstyle plugin. (And gain even more productivity)
  Abolition of code ownership: Say goodbye to quality, accountability, job-satisfaction.
  Discrimination against non-XPers (Kent's insistance than non-XPers be kicked out of XP teams): "Why can't we all just get along?"

  I too gave XP a few tries and putting aside the above offending
  items what I don't like about XP most is that is demands that
  humans become machines to make it work (ex: having Sir.
  Smells-a-lot be my checkstyle plugin).

  I want my machine doing the few positive aspects of XP
  for me. The rest I allow my team experiment with if they
  want to. However I make it clear from day one that this
  project is not an XP project.
  

  Posted by: jay_fuerstenberg on October 03, 2005 at 05:43 PM

• >> "Why can't we all just get along?"

  We can and should get along, just not on the same team. Missing from this discussion is the fact that this is not a hobby, there are substantial amounts of money involved if you actually ship something useful. XP people think that forming teams with certain practices amplifies their chances of shipping and earning a living.

  Having said that, I understand that particular situations can be very painful for the parties involved and that a compassionate approach is always appreciated.

  -david

  www.testdriven.com
  

  Posted by: dvydra on October 03, 2005 at 08:42 PM

• "darcy: So XP and tranditional programming are similar in this sense. Integration causes a lot of pain. Right? So what is the advantage of using XP here?"

  
  Integration is much more frequent with XP - it sucks much more in traditional development to find out that you want to change something... to the point where people don't bother making the "proper" change and just hack something in (such as using default arguments in C++).

  
  With XP you have a set of tests and a process in place to handle the refactoring. That means that, if you are following the rules in XP, changes are fairly easy to make. If you don't follow the rules then you are setting yourself up for failure/frustration.

  
  Traditional methodolgies do not cope well with changes - XP, if used properly, handles them with relative ease. That being said, if you attempt to go into XP with no idea of where you are going it isn't going to work out well :-)

  Posted by: darcy on October 04, 2005 at 12:18 AM

• I guess we all have different painful experiences. Some of my most painful ones are:

  People having code checked out for several days before integrating (oh, and usually leaving the integration problems to someone else)
  designs containing everything you thought you would need, which has to be cleaned out later because it confuses things
  Knowing that a cross-module refactoring would make things sooo much easier, but having to let it go because of code ownership

  Contrasted with some of the happier ones:

  code is integrated and all tests are green before coffee, lunch, coffee, going home
  My pair correcting my brain-fart before it starts to reek
  looking over a finished project that does exactly what it should and no more, with a nice , neat and understandable final design/architecture

  But, hey, some like coffee, some like tea, and if we were on the same team I want you on another module that has a very clearly defined interface to mine (provided we could change it if necessary ;-) )

  Posted by: tobega on October 04, 2005 at 06:07 AM

• Oh, one more thing, why do you think XP mandates shooting in the dark without knowing where you are supposed to end up? Without having a clear view of the end result, development is not doable. However, XP recognizes that the end result will most likely not end up exactly the same as any vision you had along the way. You just design for refactorability rather than reuse, so that you can ease into the patterns you thought you needed if it turns out to be necessary.

  Posted by: tobega on October 04, 2005 at 07:31 AM

• 盛大金属制造有限公司是以生产钢管、无缝钢管、无缝管以及销售为一体得大型文件柜更衣柜流通企业。我们提供论文发表和同声传译同声传译设备等Google排名服务，专注于企业的SEO优化培训！

  Posted by: jlj714 on October 21, 2007 at 07:45 PM

• 网站优化-搜索引擎优化-Google排名-Google左侧排名-SEO

  Posted by: jlj714 on October 21, 2007 at 07:45 PM

• 欢迎广大客户订购威震生产线及工业流水线.销售电话:0576-86678139 合作伙伴:流水线博客网
  

  Posted by: sunhuanjun on November 18, 2007 at 11:16 PM

This work is licensed under a Creative Commons License.