The term “tracer bullet” comes from incendiary ammunition that gunners use to plot the trajectory of their shots.
“Their phosphorus ignites and leaves a pyrotechnic trail from the gun to whatever they hit,” write authors David Thomas and Andrew Hunt in their book The Pragmatic Programmer. “If the tracers are hitting the target, then so are the regular bullets.”
It may seem strange to read about ammunition in a book on software development, but tracer bullets in software similarly light the way ahead for development teams.
What Are Tracer Bullets?
- Bare-bones exploratory code that can be 100 percent disposable — a single call to a new API, for example.
- They help answer questions that come out of the planning process about how things may work in practice — if you don’t have questions, you don’t need tracer bullets
- It’s a quick, iterative way to test if new technologies work within the context of your project.
The book explains that, after a project’s architecture has been decided, tracer bullets can be used as a quick way to test its viability. Developers write code that forms the “skeleton of the final system,” hitting all of the major components of the project such as the user interface, authorization layer, business logic and database.
For instance, if developers are using a third-party API for the first time or are interested in storing data in a new type of database, they can write code that makes a single call to the API or stores a single item to the database to get an idea of how it would work within the context of the project.
Through this code, developers are able to check that all the components are able to work together and immediately pivot when they don’t.
Tracer Bullets Allow You to Iterate Faster
Tracer bullets are less common than other tools in agile methodology. Drift, a tech company based in Boston that makes marketing chatbots, makes extensive use of the technique, but director of engineering Bernard Kiyanda hadn’t encountered it in his previous jobs.
“I had not heard that term before — and I come from an agile environment,” Kiyanda said.
At Drift, tracer bullets are an important part of the software development process — and the company doesn’t use agile.
“We have our own flavor, which is faster moving,” Kiyanda said.
Each of Drift’s teams consists of three cross-functional developers, and also a product manager and designer that the developers share with one other team. Everything is designed to enable development teams to move quickly and prevent bottlenecks, including the company’s adoption of tracer bullets.
“The tracer bullet definitely has more of a hackathon-style approach.”
“I think that’s really, in the end, why we run them — we need to iterate faster,” Kiyanda said. “The tracer bullet definitely has more of a hackathon-style approach. It gets to the answer as quickly as possible — and [lets you] be creative about it.”
He explained that, when a project is initially scoped out, the team gathers requirements and comes up with a series of “stories” that act as blueprints for development. But there still may be lingering questions that come out of this “story time.”
These could be questions around whether a particular architecture could deliver the necessary performance and speed, or about unfamiliar tech stacks, libraries and APIs. While many of these questions may be answered through more planning and research, some answers are easier to find by coding something up and seeing how it works.
“That’s the part that is a tracer bullet — we frame it around a specific question that we want to answer. Sometimes you have to start coding to understand the answer to it,” Kiyanda said. “If coming out of a story time, there are no questions about how we go about executing and developing that solution, then there is no tracer bullet needed.”
Tracer Bullets Are Different From Prototypes and MVPs
At first, tracer bullets may sound similar to prototypes or MVPs, but they aren’t quite either, Kiyanda said.
“Prototypes are probably going to last sometimes more than a week, sometimes more than several weeks,” he said. “If we were to do this at Drift, we’d say, ‘How are we going to break this prototype down into increments of several stages of tracer bullets?’”
The goal of a tracer bullet is to figure out whether a potential concern is valid or not. Unlike prototypes, which are often demoed when they are finished to show off the capabilities, tracer bullets can be either discarded or incorporated into the rest of the codebase once the original concern is addressed.
At Drift, developers are given ownership over tracer bullets that they write and work within strict time frames to ensure that tracer bullets focus on addressing necessary concerns.
“We timebox them,” Kiyanda said. “They can take a day or they can take up to five days.”
Tracer bullets are also different from the idea of the MVP — or minimum viable product — although the two ideas do share some similarities. An MVP is a working product that customers can begin using, while tracer bullets are only created to test a concept and are not fully fleshed out.
“There can be an overlap with the MVP, but in most cases, because we don’t put a requirement of being ready for general availability, it could also be 100 percent throw-away code,” Kiyanda said. “We basically want to understand what type of customer value we can get, as quickly as possible.”
“Because we don’t put a requirement of being ready for general availability, it could also be 100 percent throw-away code.”
In other words, tracer bullets are written as a dry run to test whether new architectural designs and technologies are feasible for a given project. If it works, the tracer bullet might be incorporated into the codebase, which eventually becomes the MVP. At Drift, all tracer bullets go through the entire development lifecycle, separate from the rest of the codebase, and end up in the production environment so that developers and customers are able to see it.
“It’s an end-to-end solution,” Kiyanda said. “It needs to actually be in production so we can actually test it with our clients.”
This is useful especially for tracer bullets that are created to address concerns about how front-end components should behave. With the tracer bullet in production, customers are able to interact with a live product and decide whether a particular design works within the context of the larger application.
Because of their flexibility, tracer bullets are used across a wide range of solutions at the company, from scoping out third-party APIs to AI teams that train the chatbot classifiers. Drift also uses them to decide how customers would like to customize their use of Drift’s products, like their widget.
“Drift has a widget that we provide, where customers can run a chatbot with a specific configuration,” Kiyanda said. “Those widgets are loaded in the end users’ browsers. We iterate a lot on trade offs there — on content versus performance.”
Using tracer bullets allows the company to quickly try out different customizations and be “scrappy” about getting feedback from the customer, rather than spending a lot of time on set up.
“It’s the least amount of coding that someone has to do,” Kiyanda said. “Reuse what you can and try to glue together pieces that exist already, for the purpose of finding the answer to the question you’re trying to solve.”
