Tracer bullets are a really useful and evocative metaphor in the context of writing software when we’re given a set of vague requirements because our customers don’t know or can’t express what they really need or want.

Tracer bullets are loaded at intervals alongside regular ammunition. When they’re fired, their phosphorus ignites and leaves a pyrotechnic trail from the gun to whatever they hit. If the tracers are hitting the target, then so are the regular bullets. Soldiers use these tracer rounds to refine their aim: it’s pragmatic, real-time feedback under actual conditions.

That same principle applies to projects, particularly when you’re building something that hasn’t been built before. We use the term tracer bullet development to visually illustrate the need for immediate feedback under actual conditions with a moving goal.

Like the gunners, you’re trying to hit a target in the dark. Because your users have never seen a system like this before, their requirements may be vague.

The Pragmatic Programmer - Tracer bullets

When faced with uncertainty one classic approach is to specify the system to death to make sure that you’re building the right thing.

An alternative is to use the equivalent of tracer bullets in software development: You select one of the areas with the biggest risk or doubts and you build it end to end. That is, rather than building a perfect single UI component, you build a slice of the system that represents and end to end feature across all layers.

It doesn’t have to be perfect, but because it is functional we can share it with customers and other stakeholders like UX or PMs to find out how close to the target (the desired system) we are. With their feedback we can incorporate improvements to get closer to the target and continue developing other features incrementally following the same approach.

Some advantages of tracer bullet development are:

• Users and other stakeholders can experiment with a working feature early and provide feedback.
• Developers build a scaffolding to work in. This is a natural way to parallelize work when working with a team. Part of the team can work on establishing the skeleton of a feature and the rest of the team can polish it.
• You have a better feel for progress.
• Removes uncertainty and fear of the unknown
• Tackles the hardest problems first

Tracer bullets vs Prototyping

They are related concepts but different:

• Prototyping is about exploring a specific aspect of a system. The main purpose is learning. After you’ve learned from the prototype you’ll throw away the code and rewrite the system using the lessons learned from the prototype.
• Tracer bullets are about building a slice of the system end to end to remove uncertainty and gather feedback. It’s production quality code albeit a lean version of it.

The distinction is important enough to warrant repeating. Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. Think of prototyping as the reconnaissance and intelligence gathering that takes place before a single tracer bullet is fired.

The Pragmatic Programmer - Tracer code vs prototyping

Additional Resources

• The Pragmatic Programmer book by Andy Hunt and Dave Thomas
• The Growing Object-Oriented Software, Guided by Tests book has a similar concept to tracer bullets called a walking skeleton.