Buy Dont Build

"Buy Don't Build"

Has been proposed as one of the ExtremeProgrammingPrinciples, i.e not one of the ExtremeProgrammingCorePractices, but a valuable adjunct to Xp.

Consensus opinion regarding the buy-vs.-build debate seems to be

Buy something whenever there is less risk and less cost than building it yourself.
Buy big things (operating systems, compilers, database engines) and build small things.

Best Practices for Evaluating and Using Off-the-Shelf Products

Thoroughly evaluate the product before purchase. (If vendor does not allow pre-purchase evaluation, then cross them off your list.)
- Stick with well-known stable vendors.
- Evaluate technical support and user community surrounding product.
- Get a feel for how often updates to the product are released. There is a "sweet spot": frequent critical updates can be a sign of low quality, but very infrequent updates can be a sign of lax maintenance.
Buy a product only when it decreases risk. If you don't understand how the product works, or if you don't believe claims about its capabilities, then don't buy it until those issues are settled.
Buy the simplest, cheapest product that meets your needs. Don't buy expensive products with lots of features you don't need, even if you think those features might be useful someday.
Be wary of long-term commitments and vendor lock-in.
- On the other hand, if the customer is already committed and locked-in to a useful product, then you may as well use it.
- Don't be reluctant to throw the product away later if it turns out you don't need it--see SunkCost.
Write UnitTests for the product to verify that it does the things you need it to do.
Products that ship with source are more valuable than those that don't. However, you should never, ever modify the source unless absolutely necessary.
Always have a "Plan B" in case the product doesn't work, is incompatible with other off-the-shelf products, the vendor drops support, the vendor goes out of business, etc.
Use the DependencyInversionPrinciple, FacadePattern, ProxyPattern, AdapterPattern, etc. to isolate the rest of your application from the product-specific interface and implementation. Don't go overboard; keep it simple and only wrap the parts of the product you actually need for your application.

Shouldn't that be write AcceptanceTests for the product...?

BuyDontBuild usually inhibits refactoring:

Bought software often ships without source code.
When you do get source you tend to be wary of making changes in it, because you'll have to do them all over again when a new release comes out...

Let's drop BuyDontBuild from the list.

Disagree. I think there are obvious dimensions to application development where BuyDontBuild makes perfect sense: When a transaction monitor is required, we don't build the CustomerInformationControlSystem (CICS) again, we don't build relational databases, and we generally don't build Java, Smalltalk, C++, etc from scratch every time we start a new project just because YouArentGonnaNeedIt.

One of my colleagues is always telling me that I could have just used some widget or other which does for you something I had spent a CuplaDays coding. I'm sure he's right, but:

there are actually 20 such widgets on the market. How long do I spend choosing the right one?
how long will it take me to learn the interface?
how long will it take me to understand the source later if that turns out to be needed?
how long will it take me and others to go through the purchasing/licensing process?

My coding time versus the cost of the widget is not the appropriate comparison.

This is the opposite extreme to building a relational database. Perhaps the principle should be BuyDontBuild big things and BuildDontBuy little things.

Wishful thinking: I wish I could have pieces of software with a seal of approval, it would help me decide whether to buy or build my own.

It all boils down to answering the following questions:

Is that piece of software loose coupled enough?
Is it customizable enough?
is it simple enough for use?
Does it suit my needs?

I think a programmer should assess by his needs (question 4.). The rest should be ready made approved by a third party one can trust.

Is it making sense?

I don't think this makes sense. Criteria such as "loosely coupled enough", "customizable enough", "simple enough", and "suit my needs" cannot be judged by a third party. Only you can judge the usefulness of a product for your needs. The problem with any seal-of-approval is that the criteria used to gain approval generally have little to do with the actual quality and usefulness of the product, and much to do with lots of documentation, high-ceremony procedures, and marketing. The danger of relying upon seals of approval is that (a) you stop making intelligent decisions and (b) it eventually leads to organizational rules that prohibit the use of unapproved products.

Most often, the buy/build economic trade-off tilts to buy because of risk. We reason that, although we believe we could build something better, we are not absolutely sure, so we will accept the buy solution even if we know it will cost more in the long run. Extreme programming tips this balance and could therefore be said (on average) to be against buying. In one exceptional case, an xp team chose not to use a substantial reusable component that they had written themselves for the very project and that I had reviewed and said was ok. Why would they do this? The customer, to whom "parameterization" of the reusable model fell, considered the parameterization to be of higher risk than just writing what they wanted on StoryCard(s) and letting the team implement it over again. Quite a reversal of the norm, no? -- WardCunningham

My experience has typically been of the latter. In many cases, programmers will tend to minimize the risk of developing something themselves versus the advantages of having an existing implementation. There are no bugs in vapor-ware. Also, the bureaucratic justification and purchase hurdles for external software often tilt the balance even more towards "buy." In general, buy or reuse big items; and develop small items yourself. Go with a well known vendor (or in 3 years you will be reimplementing the component yourself). Go with "vendor lock-in;" you are better off working with known contacts for helping with implementation difficulties than building relationships from scratch in crisis mode. Try to do product evaluations and make a build versus buy decision as quickly as possible, 1 - 2 weeks with a 4 week maximum. After that, commit to your decision and make it work. -- WayneMack