Darrell Norton's Blog [MVP]

The problem is you get into an argument about what is "exorbitant." I would say that they should eat the full cost of the changeover.

Yes, if the application was layered properly it would only (or mostly) be the UI. However, if the customer specifically requested fast over good, then it may take more than that. The customer should be the one making the tradeoffs on the management triangle.

The cost of the changeover will probably be viewed as exorbitant by any business user (except the most savvy, who probably wouldn't lead you this far astray anyway) since I have found there is a severe disconnect between business users/customers and developers (technical people in general).

I find it humorous when the business people continually think that things you estimate at several weeks can be done in 2 days. Or that scope changes of any type don't affect the schedule.

I suspect what is meant is that the customer should indeed meet the full cost of the change, but NOT some arbitrary extra amount intended to stop them doing the same thing again. I guess this is principled negotiation applied to change management.

James and Paul: I believe Darrell had it right the first time. If it "meant" what you say, the statement would be simply:

"The customer will not pay exorbitant costs."

There would be no need to add conditions.

Everyone: While we're on the subject, what's exorbitant? Doesn't the basic principal of econimics come into play here? The cost will be whatever the market will bear. Why is such a silly statement in a programming methodology in the first place?

hehe. econimics?! sheez - I should read my posts more closely.

Yes, I think the customer should eat the full amount of the cost, but not an extra "penalty" amount. However, when given the full cost (including code changes, testing, deployment, etc.), customers consider it "exorbitant" without it really being exorbitant.

Exorbitant is in the eye of the beholder.

I think the what they were trying to say with that statement is that a system should be designed and implemented in a fashion that is as tolerant to user change as possible. We know they are going to change the requirements, so we should try and accomodate them as much as possible. The client should still pay the full amount of the cost, but it is controlling that cost that is important.

The person who wrote it might not have used the best words, but I think they were only trying to represent the requirements flexibility that is a large part of XP.

-James

James, you have the notion exactly right.

In XP, "customer" is unfortunate jargon; most people should substitute the term "product manager". That item in the bill of rights just means that the developers must keep the code in such a fashion that they are prepared for whatever changes that come. For example, if they want to add a GUI app that works alongside their existing web app, the developers are not allowed to say, "Oh, then we have to scrap everything and start over." They will have to write a lot of new UI code, and that won't be cheap. Plus they'd probably need some network API for the GUI to talk to. But the core of the system shouldn't need to change much.

Darrell, when you say, "if the customer specifically requested fast over good," then that wouldn't be an XP project if by fast you mean "of low quality". XP mandates a number of practices that only make sense in the context of a long-lived codebase. If you are writing something that you are certain will be thrown away soon, then full XP is not your best choice.

Instead, XP's version of the fast-vs-good tradeoff is in trading off time and scope. The product manager can get something minimal fast, or something fancy later. This sounds impossible, but XP's scope control mechanisms really mean that product managers can't overload the developers by adding scope. Adding scope just pushes back the release date.

There's a difference between not focusing on "good" and poor quality. For example, if the customer absolutely needed a specific app delivered in 2 weeks, then to meet that deadline certain things would be hard-coded instead of configurable, etc. That does not mean the code is not high quality, it's just that the time was spent delivering solid functionality versus being extendable or flexible.

Building in the flexibility to "embrace change" takes time and money, which could depending on the customer's needs, be directed at something else more important.

In my opinion the quote expresses the fundamental principal behind XP that the customer has the absolute power to decide what should be developed. So it is valid that the customer decides to change the complete UI as long as he knows the costs and consequences for the project. Obviously the customer must also be willing to pay for the additional costs.

Peter - my issue was with the "paying exorbitant costs" part. That is rather subjective. While the developers can easily give an estimate that they consider is reasonable, the customer will exclaim, "That's exorbitant! And it says right here that I don't have to pay exorbitant costs!"

It all comes back to setting expectations. If you are fair and your customer thinks you are fair, they won't see the costs as exorbitant. On the other hand, if you have the client from hell (I've had several), nothing you do will ever be good enough and they will complain about the extremely low rate you offered them too!