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. (View Highlight)
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. (View Highlight)
tracer bullets may sound similar to prototypes or MVPs, but they aren’t quite either, Kiyanda said. (View Highlight)
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. (View Highlight)
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.” (View Highlight)
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. (View Highlight)
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,” (View Highlight)
