Walking skeletons and tracer bullets

Yesterday in our series looking at proofs of concept, walking skeletons, prototypes and MVPs, we saw how proofs of concept can easily get out of hand.

Today I want to make the case for a slightly different approach to testing technical feasibility: the walking skeleton.

The most common problem with the proof of concept approach is that we tend to focus on only part of the risk. In trying to answer the question “Is this technical approach even possible?” we can easily forget that it doesn’t just need to be possible. Our approach needs to be possible, scalable, affordable, maintainable, performant, usable, and all the other characteristics of a production system.

But how can we reduce risk around technical feasibility without building the whole system?

An alternative approach is to build in production characteristics from the start. Build the smallest possible grain of functionality, and create the beginnings of all the major architectural and infrastructure components, tooling and processes necessary to get that tiny bit of functionality into production, with an automated end-to-end test and a deployment process.

You’ve built a production system. A very narrow and not very valuable one, but a production system. This allows much more realistic tests of feasibility to proceed from there, using iterative software design processes.

This approach, known as Tracer Bullet Development allows you to test a lot more of your feasibility assumptions and address big chunks of risk much earlier in the development process, without the danger of deliberately shoddy approaches finding their way into your production system.

Even better, your production-grade application can sometimes serve as a foundation for prototyping and user research, which we’ll get to tomorrow.

I’ve written more about Tracer Bullet Development for front-end development here.

You can also read more about it in Andrew Hunt and David Thomas’ classic book The Pragmatic Programmer.

All the best,

– Jim