Tracer Bullets

The bigger a system gets, the harder it becomes to make changes. It is harder to reason about the system’s behavior, especially if it is highly distributed. Maybe you can reason about your immediate dependencies and a level deeper but at some point, it becomes too much. You’ll become paralyzed trying to think about all of the possibilities.

Another problem with large systems is the need to exercise caution, you don’t want to cause production outages. That’s bad for the business sure, but the guilt of causing an incident sticks around for a while. Writing code in systems like these is like trying to navigate in the dark. You don’t know if you are walking in the right direction.

How can you overcome the challenge of navigating in the endless sea of unknowns?

You use tracer bullets.

In the book Pragmatic Programmer, the authors talk to introduce the concept of Tracer Bullets. These are bullets with a small pyrotechnic charge in them. When a bullet is fired, it lights up the path it took. This lets you know if you are hitting your target. If you are not, you correct your aim and shoot again.

Reed Hastings, a co-founder of Netflix, took the tracer bullet approach when he was trying to figure out if Netflix could rent out DVDs. He didn’t know if it was possible to ship DVDs without damaging them. He didn’t know how long it would take. There were a lot of unknowns.

So he took the simplest step that would validate his idea. He went to the post office and mailed himself a DVD. A few days later it arrived at his house undamaged. At this point, he knew it was possible to ship DVDs. From then on Netflix started to grow into the giant it is today.

If we take this principle and apply it to software engineering, we get tracer code. Code that takes you from requirement to final product as fast as possible. Code that glows in the dark as the authors say, so that you can navigate complex systems accurately.

With this approach, you write just enough production-ready code (not throwaway code) that tries to meet a requirement. The goal is not to meet the requirement on the first attempt. Rather it is to understand if you are close to hitting your target and if what you are doing works. If you miss, you try a different approach. This method shortens the feedback cycle so you can move quickly.

If you are working at a reasonably big tech company then chances are you will never know the entire system, ever. The best way to ship in such environments is to employ the tracer code method: build, validate, simplify, and iterate.

Thanks for reading the article. If you enjoyed this and would like to receive similar articles, please consider subscribing. It's free, and I won't ever spam your inbox. Share on Twitter.