The Myth of Build/Buy Decisions

This one’s simple:

“If you can buy the thing you need, buy it”.

Let’s talk about the exceptions.

There are none.? Seriously.? I am absolutely telling you that if you can buy the exact thing you need, in a business, you should always buy it instead of building your own.? Too expensive...tough, you can’t build it for less.? Not cool enough to keep your killer team interested?? Sorry, find something else valuable for them to do.?

But what about the future?? What if the company that makes it is not interested in adding new features? What if they’re a dinosaur and can’t keep up?? Here I start to wonder whether you really need this thing?? Your engineers are valuable.? They should only be working on things you must have.? If someone is offering the opportunity to take the top thing off your backlog and give it to you now, rather than in 6 months time, you should be biting their hand off for it.? If the main thing that’s holding you back is that you might have to do more work next year, maybe it wasn’t so urgent after all?

The Lie

The term “Build/Buy Decision” is a lie.? If you are faced with a true Build/Buy decision, it’s only a decision in the sense that you don’t have to make the right decision.

The Truth

Companies make decisions about technical direction all the time.? But these decisions are almost always Build/Adapt Decisions.? Cases where exactly what you need is available are rare, but finding almost what you need is very common:

• Libraries which do most of what you need, but not quite all, and need extra functionality adding.
• Systems which do more than you need, and as a result might be over complicated for your use-case.
• Software which was never intended for your use case, and so needs effort to adapt to your world.

The Cost of the Decision

Why am I labouring the point that really Build/Buy decisions are Build/Adapt decisions?? The conventional wisdom is that to make a Build/Buy decision you need to weigh up several factors such as total cost of ownership; features; security; and support; in order to compare multiple options.? This is true.? However, in order to make a useful comparison, you’ll also need to think about:

1. What are the features we’ll need in future which might affect our decision?? Not every feature we could ever need, but the ones which might mean that 3 months after launch we’re talking about ripping out the system and starting again.
2. How much effort is it going to be to work out if this is the right solution? Ask an engineer this question, and depending on the engineer, you could get any answer between: “Yeah, I’m sure it will be fine, let’s go for it!”, and: “Until I’ve built the complete solution, I won’t know”.

These two questions will usually be far more important (and expensive to answer) than answering all the questions about whether library X has a particular feature.

Pragmatic Engineering?

To correctly evaluate an option, you’ll be comparing it against not just today’s requirements, but the requirements some distance in the future. How far? You’ll need to take a decision.

You need to put some effort into evaluating options. This could be anything from a brief paper exercise based on some Googling to building a full-blown prototype. How much effort is the right amount? Again, a decision.

The secret is not to eliminate all of the uncertainty; it’s to ensure that the person or people who make these decisions have enough knowledge and experience to make them.? They will need deep understanding of both the product vision and the engineering.? To achieve this, close co-operation between engineering and product is vital.

Conclusion

If exactly what you need is available, buy it.? Otherwise, work out what you need to know to evaluate the options, including both product and engineering.? Be pragmatic. Don’t take a decision until you are confident you can handle the expected product use cases.? But also accept there will be a level of uncertainty, and there is a great value in making a decision which looks good enough, rather than spending too long making the best decision.

?