Vendor Choices

In http://groups.yahoo.com/group/extremeprogramming/message/29715, on the XpMailingList, we hear the laments of a bad vendor choice.

A company paid $4,000,000 for a product that forced a 1:1 mapping between a person and an account. They ended up needing 1:N. This forced them to switch vendors, which was a very expensive ordeal.

The poster felt that "DoTheSimplestThingThatCouldPossiblyWork" caused problems.

How can we avoid having the same problem?

Avoid Tying Yourself to the Vendor -- It should not be expensive to fix problems like this. If you constantly refactor your code to eliminate duplication then a design decision like this will not be spread all through the code, but will be in few places. -- RalphJohnson, in http://groups.yahoo.com/group/extremeprogramming/message/29781

: Unfortunately, in this case, the problem was the expense of financially committing to one vendor then switching to another. (Read on...)

Estimate both ways

: I have been bitten badly by poor vendor choice. My approach now is to estimate the system both ways, which implies gaining enough experience in both alternatives to estimate. -- KentBeck in http://groups.yahoo.com/group/extremeprogramming/message/29755

Communicate Assumptions -- Don't assume that a certain requirement is fixed unless you are absolutely sure about it.

: What happened to you was a communications problem. One of the core business assumptions was not communicated to the developers, and the cost of implementing that core business assumption was not communicated back to the customer. So there was a surprise. The likelihood of this happening on a well-functioning XP team is very small. The likelihood of it happening on *any* well-functioning team is very small.
: How do you paint yourself into a corner? Easy, you don't think about the repercussions of your actions. XP does not recommend this. XP recommends implementing only what is necessary for today's stories. That doesn't mean we ignore the repercussions of our actions. We communicate those repercussions to the rest of the team, including the customer. -- RobertCecilMartin, in http://groups.yahoo.com/group/extremeprogramming/message/29756

Use small systems with automated tests

: My critical success factor is that the whole framework, including test cases, must be able to be redeveloped from scratch on the train from Munich to Erfurt. The frameworks I come back to time and again have this quality. You learn more each time, and you learn more about what you can leave out. -- KentBeck, in CriticalSuccessFactorsOfObjectOrientedFrameworks
: If the systems had simple designs and good test cases, if would be much safer to reuse them. --RalphJohnson, ibid.

Don't use 3rd party systems at all.

: Many XP people try to avoid buying systems and integrating them. These systems probably will be hard to change. If they don't do what you need, you will be in trouble. -- RalphJohnson, ibid.

XP can't save you from manegerial incompetence. They needed 1:N and decided to buy 1:1 anyways. If they built 1:1, that would be another story, as they could then upgrade it to 1:N. But by buying, they locked into a solution that didn't do what they needed.

I question whether this is related to XP at all. Is there any other methodology that would be able to recover from a decision like this any easier? In fact, XP gives you an advantage in this situation because your own code is more flexible, allowing you to either build a 1:N solution or buy one and adapt your code to map to the new system better than your average code will. --RobMandeville