Software tracer bullet

Components have been fleshed out and therefore more code needs to be changed. As a result of delaying the discovery of such problems, you actually are creating a false sense of progress.

For an application, this is unacceptable, as you may need something to demo for your client or supervisor. On a smaller scale, the feedback you get from seeing something work early on is invaluable. Using this approach creates a very loose feedback loop. Writing faulty code now will result in problems much later, and tracking down the culprit will be much more difficult after other code has been written. In The Pragmatic Programmer: From Journeyman to Master , the authors describe a method for developing software called tracer bullets.

The key benefit to this method is to get quick feedback on a variety of factors. It serves as proof that the architecture is compatible and feasible, as well as providing a working, demo-able skeleton to work with very early on in the development process.

In practice, I believe this approach can work at both high and lower levels; both when creating a new application from scratch or adding new functionality to an existing application. You can accomplish this by implementing the most basic, fundamental part of the new functionality and improving it incrementally as you flesh out each component.

By implementing a small part of each one and connecting them early on, you force yourself to do this. This brings the discovery of potential problems with your overall design much earlier in the process. This means fixing them is much easier, as there is not as much code to fix and you can adjust your design accordingly going forward. Coding without seeing your code in action is often like coding in the dark.

With no immediate feedback, you are further and further obfuscating the causes of potential issues you may face down the road. Using the tracer bullet approach means you get a working version early, though the functionality may be basic. This means you have something to show for your work early on. In the spirit of getting fast feedback and growing code, you want to use a TBD approach to all development. This work flow forces you to create vertical slices of functionality. These metaphorical bullets move from the front end code all the way through the lowest layers of the system.

This allows your team to quickly understand which architectural and technical decisions will work, and which may not work out the way you expected. It also forces different groups to talk. This is absolutely vital to the success of larger projects, especially in a larger company where functionality might be implemented across teams. You must find a way to communicate in an unambiguous way to other groups of people. History has proven that the written word is insufficient.

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. 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.

Tracer bullets are less common than other tools in agile methodology. It gets to the answer as quickly as possible — and [lets you] be creative about it. 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. 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.

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. 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.

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. We iterate a lot on trade offs there — on content versus performance. This experimental agile tool lights the way ahead for developers. Tammy Xu. September 9, Updated: July 8,