lefel

Let's Talk About Tracer Bullets

4 min read management product tech Ler em português

Cover

Prioritization is one of the most delicate points of project management. During the conception of a new piece of software, in an animation pipeline, in the design of a new system or of a new feature to be implemented, we always split development into several parts. But how do we prioritize what needs to be done?

Some choose to start with the easiest part, others with the hardest, but both sides ignore something very important: improbability.

Sometimes the part you thought was easy is not that easy and will delay the rest of the development. Or you may find that the part that looked so hard was not that hard after all, but because of it you ended up losing visibility of a difficulty that came later.

It can be a technological improbability, a team one, an integration one, a people one or even a business one. Improbability is always a constant in many shapes and, in the software industry, it is also the cause of many bugs.

Many try to mitigate this factor, but eliminating it is impossible. One of the tools we can use for that are tracer bullets.

To explain tracer bullets, I prefer to use a real case:

One day I was working on a test that consisted of building an API with 3 endpoints which, in the end, queried a third-party API. One endpoint saved a resource, another listed them sorted, and the third found a specific resource in the API. My first question was: what should I do first?

So I used a slightly different approach: I picked the feature that is the simplest, but that covers the software from one end to the other; in this case, the third endpoint.

Here, the third endpoint of the task had a few main layers:

All the other endpoints would use these same layers. The only thing some endpoints would have that this one does not is a data repository layer but, honestly, with the whole system already built, the improbability of that part is minimized.

With this approach almost every part of my system was “illuminated”, and if there were any problem with them I would already know, and if there were none, I would know that too, because they had been implemented.

This approach I used is called tracer bullets, and it preaches prioritizing a feature that covers the software from one end to the other, even if it is a basic feature, because it reduces improbability.

It even gets its name from the saying: “If you are going to shoot a machine gun in the dark, you have two options: the first is doing a lot of math accounting for the bullet’s weight, the air, the gun’s recoil, and then shoot. The other way is using a tracer bullet that glows between some bursts. If the tracer hits, the bullets are hitting. If the tracer misses, you know where you have to recalculate. And since this tracer exists in the real world, it reduces improbability.”

And that is what a tracer bullet is: a feature that implements every layer of the project from one end to the other, which tests whether the project itself works and stands on solid ground, reduces improbabilities and, after that, the whole rest of the project gets attached around it.

Link knows how to use Tracer Bullets in the new The Legend of Zelda Tears of the Kingdom

A less technical example can be the animation business. If we were making an animated feature, in order to develop an innovative animation style or a different piece of storytelling, it would be easier to produce one part of the animation from end to end, instead of testing the whole storyboard around an animation style only to find out later that this style is not the right one.

The second option is clearly more expensive, and that is why companies like Pixar, Dreamworks and Sony Animation Studios use the first process.

Remember this is different from a POC (Proof of Concept, for the startup crowd) because those are usually disposable after the test, while the tracer bullet is part of the project and will even serve as the foundation for the other parts of the project to be implemented around it.

So, to recap, Tracer Bullets are points that cross your project from one end to the other so you and your team can reduce improbability. And that is a good item to prioritize in your project because, if you get one of these right, you already have a good part of the layers and steps mapped, and you reduce errors. Therefore, I always recommend checking where there are end-to-end items in your software with some point that could go wrong, and prioritizing them.

We also learned that, although this was born in the software industry, it is not exclusive to it. We can use it in any industry, actually. I plan, of course, to bring other means of healthier project development in future articles.

Bibliography: