In praise of the discovery build

03/05/2017 - 13:22


Save articles for future reference.

OPINION: Discovery builds are an ideal part of the development pathway for startups seeking to minimise risk.

In praise of the discovery build
Programming is a complex, creative process. Photo: Stockphoto

OPINION: Discovery builds are an ideal part of the development pathway for startups seeking to minimise risk.

As I was meandering through the leafy glades of the internet the other day, I came across a video of a woodworker making a fantastic folding table. Nothing unusual there, of course, as there are plenty of these sorts of videos online.

However, what interested me was that the video was of a ‘discovery build’. The woodworker had used cheap wood for the project because he planned to throw it away at the end. The purpose of the project was not to create a fantastic folding table, it was to discover how to make fantastic folding tables.

Software products are many times more complex than folding tables, and our need for discovery builds is that much greater. Computer science refers to this as ‘prototyping’.

There’s a famous quote from Fred Brooks, author of the industry classic The Mythical Man Month:

“Plan to throw your first version away,” he writes. “You will anyway, so you might as well plan to do it.”

Most developers do discovery builds on their own side projects – they’re the easiest way of finding out how to build something. Programming is complex, and the best way to build a system isn’t obvious, so a discovery build lets us explore the problem and find out what works (and what doesn’t).

I’m on the fifth build of one of my projects. I tried three different technology stacks and a couple of different architectures, and the solution I ended up with is much quicker, more responsive and flexible than my first attempt.

Programming is a creative thing, it’s not deterministic – there is no single way to write a program that solves a given problem. In fact, there is an infinite number of ways to write any program. Each one of those infinite ways has a different performance profile.

Some are faster to execute, some are easier to understand, some are quicker to develop, some are smaller, and some are easier to modularise.

We can rarely choose our optimisation when working on a new problem. The first build is all about understanding the problem; once we’ve understood the problem, we can work out the best solution and optimise it.

Of course, most commercial systems are more or less identical. There’s a database at one end, some business logic in the middle, and a user interface at the other. After a few years in commercial development, a developer has built half a dozen of these. No discovery build needed. There’s a clear plan for these types of systems that we can follow because so many have done it before.

However, a prototype is necessary for startups creating new technology. Creating a rough prototype fast lets us explore the interesting parts of the problem. We can use the prototype as a framework to try different approaches. We discover the tricky bits fast, without spending much time on the mundane bits. 

From a business perspective, founding a startup is also creative rather than deterministic. There is a huge range of options for the business, and very little in the way of instructions. Customers may not have the problem the startup solves, the team may not be able to build the solution, the market may not be ready for the product and the technology may not work – all of which is perfect ground for a discovery build.

Lean startup talks about the ‘minimum viable product’ or MVP. A much-misunderstood concept, it is a discovery build for a business model. It lets us test whether the customer will actually buy the solution for their problem, and it lets us experiment with the business and explore the market for it. We can try different revenue models or marketing strategies with a cheap prototype. Then, once we’ve established the viability of the business, we can hit the market with the full product.

Established business models don’t need MVPs because they follow an established pattern. Building a new hairdressing business is a matter of following the plan. The plan is already known because so many have done it before. Even the banks know how these businesses work and will lend money to them, so you know there’s no risk here.

Startups are high risk; this is what makes them so profitable when they work. For lots of different reasons, however, most fail. Trying to contain some of that early risk to a cheap disposable prototype is good sense. Discovery builds work for craftsmen, programmers, and founders.


Subscription Options