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

Best Practices for Evaluating and Using Off-the-Shelf Products
Shouldn't that be write AcceptanceTests for the product...?

BuyDontBuild usually inhibits refactoring:

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:

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:
  1. Is that piece of software loose coupled enough?
  2. Is it customizable enough?
  3. is it simple enough for use?
  4. 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


See also: VendorChoices, BuildDontBuy, InfrastructureInXp, AvoidOrEmbraceLibraries

EditText of this page (last edited September 14, 2004) or FindPage with title or text search