Greg Vaughn's Blog

Fundamental Problem with Extreme Programming

XP requires too much of an investment from the business. Even aside from the obvious on-site customer that XP requires (and Mr. Stephens makes a good case that the best you'll get is a junior person) there's the regular unfinished (and unpolished?) versions of the software they're expected to use and give feedback about in the Planning Game every few weeks. There's also the ideal of the business users working to develop the acceptance tests.

It's like watching sausage being made. Business users are not techies, and generally don't want to become techies. They want the software, and they want it with a minimum of their effort. The overall development efficiency that XP is built around actually decreases the business users' efficiency in doing their own job during the development. They find it tiring to think like a techie and answer all the detailed questions about how various requirements interact and handling all sorts of 'what if' scenarios.

Please, don't misunderstand me, gentle reader. I do respect XP. It has served as the spark that got people (me included) thinking more about Agile methods in general (though the ideas go back much further than that). I've written in more detail about why I choose to associate myself with the Agile movement rather than XP before. The gist of which is best explained by comparing XP to Free Software (FS) and Agility to Open Source Software (OSS). XP/FS adhere to uncompromising purity of their ideal. Agility/OSS agree with those ideals, but realize compromises must be made in the name of practicality. XP/FS have actually become special cases of the broader Agility/OSS categories.

I guess I'm just a practical sort of guy.

Comments

• That's just Software Engineering
  Surely the problem of users wanting software to just "appear" with little or no effort on their part is just a fact of life in software. Don't they have to answer lots of questions and "what if" scenarios regardless of the development process? XP might demand more of them, but it's not going to alter the fact that they have to tell the techies what they want one way or another.

  Chris

  Posted by: chrisrimmer on August 12, 2003 at 01:00 AM

• Requirements are hard, and painful ...
  Unless I miss understood something, this is a fatal position. Gathering requirements is one of the still under developed areas of software engineering. Absolutely critical to successful projects. Personally I don't care that much how they are gathered. It can be formal or XP style. Depending on the development team setup and staff, either can work. XP style is difficult with large or remote teams. Formal is slow and can get key issues wrong. Whatever, I do believe it's a major mistake to believe (or even consider) that the "business" can get away without the "serious pain" of being "deeply involved" in specifying what they want from "their" software.

  Posted by: robin_shorrock on August 12, 2003 at 01:26 AM

• Requirements gathering problems
  We probably don't admit it outside out own small working groups, but we all hate writing requirements. I personally don't like that part of my job for a very obvious reason - I'm not a business person, I don't understand the domain fully, and I'm always extrapolating from a small and informal document to something we can write software against.

  To make matters worse, in my case I've worked mainly in telecomms and finance, and in both domans I'm trying to fit new functionality onto big, complex legacy systems that I don't fully understand.

  Agile methodologies are very appealing, but the reality is that in many industries it can be very hard to actually meet a client, of any level. I've been a programmer since 1998, and I've never talked to a client during the requirements process!

  So, do I think XP is flawed? Nope. I think XP is idealistic in assuming that a client representative is always available for all industries, or that they understand the whole business in detail anyway [*], but I also think that the rest of us are deluding ourselves into thinking that having someone other than the client writing the detailed spec is okay...

  [*] Yes, I realise 'client representative' may mean a team, but again, for a complex domain you may easily end up needing a team of business experts from several depts to answer queries from the programmers. As we poor coders are usually under time pressure, and business people are also busy, it's natural that assumptions are made to make progress.

  Posted by: david_kennedy on August 12, 2003 at 03:07 AM

• religious conflict
  I know the whole religious war thing is an old saw, but it never fails to surprise me that in software, as in religion, the harshest criticism seems to be reserved for those closest to you in beliefs.

  The average software developer (don't get me started on managers) doesn't know the difference between XP and Agile, nor Free Software and OSS for that matter.

  To outsiders I'm not sure who sounds crazier, the guy giving away software because of his moral principles or the guy giving away software in order to make money.

  As for this XP backlash that's going on, the XP proponents are so uncompromising (you must do this, must do that, small teams, on-site customer etc. etc.) that you could just *agree* with them and concentrate on the 99% of software projects that will never fit their rules for various good reasons.

  But instead the general plan of attack seems to be "people can't follow rules therefore we need more rules" mixed in with a fair amount of ad hominem attacks and misrepresentation of XP in theory and practice that amounts to FUD (not referring to you specifically here but definately including the article you link to).

  I feel forced to conclude that people are just riding on the coat-tails of the buzz that XP has (deservedly or not) generated, which after all is said and done is not a crime, but does leave me feeling slightly manipulated in a way that an honest discussion of the faults of XP wouldn't.
  

  Posted by: bawjaws on August 12, 2003 at 05:32 AM

• Some thoughts
  I read the Stephens article a few days ago, and I agree with you: he's trying to sell you something. There were several places where it seemed that his argument just didn't work, but he shoehorned it in anyway. Some nice points, but overall I think they've all been said better in other places, especially Wiki.

  > XP requires too much of an investment from
  > the business. ... there's the regular unfinished
  > (and unpolished?) versions of the software
  > they're expected to use ... business users
  > working to develop the acceptance tests.

  Just a few observations, here. First, that investment is crucial to developing good software, where good == "delighting the customer". If the customer doesn't figure out what they want, you'll never be able to build it. Agile requirements gathering makes it much _easier_ on the customer than a long, formal requirements phase. Agreed, other Agile methods may require less investment than XP, but they all require an involved customer.

  Second, if you're doing it right, those unfinished releases are _useable_ ... they aren't just there to get feedback, although that's a valuable part. They're there to provide value to the customer. The customer should be able to do something with them...and know that bugs they find will be addressed in weeks, days sometimes, not months. That's a really great feeling, as a customer.

  Finally, business users always develop acceptance tests. XP requires that they write them down.

  > the Agile movement rather than XP before.

  XP is an important part of the agile movement. If you look at what Alistair Cockburn and Jim Highsmith (amongothers) have been working on, you could make the case that each team should "roll their own" methodology from Process Patterns/Best Practices. Agile becomes a philosophy, not a metodology.

  > The gist of which is best explained by
  > comparing XP to Free Software (FS) and
  > Agility to Open Source Software (OSS).

  Instead of FS, perhaps you should have said FSF? "Open Source Software" is just a re-marketing of "Free Software" ... they have the same definition.

  I'd also disagree a little that non-XP agile methods "compromise" on purity. I think many of them just have a different approach, but are just as ideologically inline with the Agile Manifesto.

  Nice comments! I'm very glad to see people talking about process here.

  Posted by: mdi on August 12, 2003 at 07:01 AM

• Teamwork and Communication
  XP values many things, including Communication and Teamwork. It acknowledges that the customer is a member of the team.

  Programmers and developers are concerned with the Technical Problems.

  The Customer is concerned with the Business Problems.

  Not allowing the customer to be fully involved in the process is to doom the project. The customer is the one that understands the business, and therefor is the only one that should answer the "what if" questions about the business.

  XP allows the customer to drive. It might seem like more work, but what's harder: light-weight user stories and to answer questions along the way, or to do cumbersome full requirements gathering that result in up front committments? I would imagine the customer A) doesn't know all the answers now and B) would want the option to shuffle things around a bit.

  By allowing the programmer to make the technical decisions and the customer to make business decisions, all parties are happy and focused in what they do best.

  Posted by: sethladd on August 12, 2003 at 07:11 AM

• Requirements are hard, and painful ...
  Absolutely. If the business doesn't want to be part of the requirements definition and evolution process*, they will get the system that the developers want (or what they think the business users want), which likely is at least a bit different from what the business wants or needs.

  * I call it this because requirements are not just hanging out there, waiting to be "gathered" like berries on a bush. Requires must be definied, and these definitions must be maleable as the system evolves, and as the developers' AND the users' understanding of their needs grows. This realization that requirements cannot be "gathered" is vital to project success, and central to any agile methodology.

  Posted by: jimothy on August 12, 2003 at 07:56 AM

• Requirements are hard, and painful ...
  The belief that defining requirements must be hard and painful likely comes from more formal methodologies, where customers are expected to have remarkable foresight to predict every single nuance of the system requirements upfront, and not to have to change their mind during the course of the multi-month (or beyond) project. How is it that we expect such prescience out of our customers when we ourselves admit that software development is unpredictable?

  The remarkable thing about an agile methodology is that by getting the customer involved, requirements defition is actually LESS painful.
  

  Posted by: jimothy on August 12, 2003 at 08:22 AM

• Clarifications
  Yes, this is primarily about the difficulty in extracting requirements. It is much more akin to digging deep for stubborn wisdom teeth rather than gathering manna lying on the ground each morning.

  I'm not trying to make the point that the business should not be intimately involved with the software development process. I'm saying that they will not in the majority of cases because they don't want to. They see the monetary investment as the extent they should be involved.

  XP doesn't have a good contingency plan for this practical issue. Under the umbrella of Agility, we can/should customize the methodology to the concrete situation at hand. This customized methodology is often not the most efficient in terms of pure software development because it has to work with the real world situations of business users not wanting regular interruptions to their job.

  Really, the optimal situation is when the developer(s) learn the business itself. Does the XP motto "Specialization is for Insects" apply to the specialization distinction between developers and business people?

  Posted by: gvaughn on August 12, 2003 at 09:30 AM

• Clarifications
  >Really, the optimal situation is when the developer(s) learn the business itself.

  Well, I'll state right off I'm not big on XP, so take my comments with that in mind :).

  
  But I think Mr. Vaugn hits it on the nose. The best case is for developers to understand the domain. Case studies on the most efficient and effective projects show a deep, deep understanding of the domain and related business concerns.

  XP, in my view, tends to encourage less understanding. "Let's get the basic idea from the customer and start coding! The customer will tell us when things are wrong." The problem is, lots of little decisions are made the customer doesn't see. Pieces that could be reused on other projects, or the same project later down the line, if only the developers really understood the the underlying business.

  XP "solves" this by constant refactoring. Hey, we did it wrong, no problem, we'll refactor it now. But that's a very reactive, rather than proactive, way to do things. You're always making a mistake and then fixing it, rather than avoiding the mistake in the first place.

  "Wait!", I hear you say, "If you try to avoid all the mistakes you're going to way over engineer things!"

  And I'd generally agree, which is why domain knowledge is so important. You'll engineer for future needs you *DO* understand and avoid over/under engineering out of ignorance.

  And in my mind, that's one of the true purposes of having a strong requirements phase: transfer of domain knowledge.

  Oh, and someone mentioned "we all hate writing requirements". Well, I don't :P. I like understanding the context of my development. I like knowing my code should do X not because Customer Bob said so, but because Customer Bob helped me understand why he needs it. Then later, when I have an idea, I'll have a MUCH better idea of whether it's something Bob would find useful.

  Posted by: ckessel on August 12, 2003 at 02:09 PM

• Clarifications
  "Really, the optimal situation is when the developer(s) learn the business itself."

  That won't happen until the businesses that we write software for realize that programmers are not interchangeable parts, and that our jobs can't simply be outsourced or offshored and expect our replacements to have the same knowledge of the business.

  XP acknowledges the importance of domain knowledge, and does a better job of that than traditional heavy weight methodologies (where a stackful of requirements docs can be thrown over the wall to the interchangeable developers). That's the whole reason for getting the customer involved. If a developer or "SME" who has spent some years with the same company can serve as the customer representative, that might be an acceptable (though not ideal) substitute.

  Posted by: jimothy on August 12, 2003 at 03:48 PM

• Clarifications
  |
  |I'm saying that they will not in the majority of cases because they
  |don't want to. They see the monetary investment as the extent they
  |should be involved.
  |

  Then they should not be surprised when they are delivered crap software.

  |
  |Really, the optimal situation is when the developer(s) learn the
  |business itself.
  |

  Agreed. But the rarity of these people should be an indication that its not an easy task to be a master of a business domain AND master of developing software.

  In the business I am in (banking), if the developer knows as much as the traders, then they wouldnt waste their time developing software -- they will BE a trader - make a shedload more money!

  Ultimately, if the business customers arent prepared to put in the effort, then you have to ask yourself is this a worthwhile project to work on...

  
  -Nick

  Posted by: nickminutello on August 12, 2003 at 06:42 PM

• Requirements are hard, and painful ...
  I agree, although the evolution process and the growth of understanding isn't alway pain free ;-)

  Posted by: robin_shorrock on August 12, 2003 at 11:23 PM

• Clarifications
  Greg says:
  "I'm not trying to make the point that the business should not be intimately involved with the software development process. I'm saying that they will not in the majority of cases because they don't want to. They see the monetary investment as the extent they should be involved."

  This is a very valid issue but isn't it up there with managers who don't understand/or care about software development ? i.e. Major, major issue.

  Bottom line is, the business has to be intimately involved. If it isn't then the project is likely to fail. Therefore business involvement (direct or indirect) has to be deeply built into the process.

  XP tackles this head on, which is good. I agree with Greg that it doesn't really have a contingency in terms of approach but then isn't this the case XP in a number of areas ? IMHO, this is one of strength and weaknesses of the whole XP approach.

  Agile processes can be more flexible but then this is also a weakness as well as a strength. More choice means more escape routes for avoiding hard issues, like ensuring deep business involvement. This sounds flippant but I'm not sure it is. One thing that is good about XP is that there is no debate.

  For me, I guess I'm a practical guy. I would hope to have a number of process approaches in my toolkit. Agile is very definitely a main one. The XP variant would be an option too.

  Posted by: robin_shorrock on August 12, 2003 at 11:32 PM

• "Specialization is for Insects" ?
  I think what XP tends to discourage is the rigid definition of people as "Analyst", "Architect", "Coder", "Tester" etc. It doesn't mean that there can be no specialists. See http://c2.com/cgi/wiki?SpecializationInXp for more on this.

  I think that most Agile folks would be against those rigid job definitions too. The pragmatic programmers say (in Tip 60 of their book) "Don't separate designers from coders, testers from data modelers". They favour splitting up teams into groups, each of which is responsible for a module.

  Posted by: chrisrimmer on August 13, 2003 at 02:46 AM

• Clarifications
  If developers don't refactor, it's not likely because they have not made mistakes. It's more likely that they either: are not familar with the concept of refactoring ("You mean I can go back and fix an awkward design?"); or refuse to refactor ("This is the design we set forth in the very beginning, and neither hell nor high water can change it!").

  Ask yourself: Are either of those a good reason for not making improvements? Are either of them likely to lead to high quality software?

  Posted by: jimothy on August 13, 2003 at 06:34 AM

This work is licensed under a Creative Commons License.