I feel slightly silly responding to a three-year-old question (and one that might be better asked on a different stackexchange), but I think there is still room for improved clarity in describing the difference between tracer bullets and prototypes.
To begin, they are different things, with different purposes. But they also have similarities. I will describe their similarities as a means of highlighting their differences.
Much of this is my own take on the concepts, so please read critically.
How They Are Similar
Both tracer bullets and prototypes are used to make headway on a new undertaking. You are creating something new; an exciting but complicated process. The unknowns are unknown. The features are not well-defined. You aren’t sure what components you will need, or how the code must be structured. Tracer bullets and prototypes are similar in that they are both used in this situation. Another similarity is that they are both focused on quick, efficient results.
How They Are Different
The two methodologies are different in two general ways: which unknowns they attempt to explore, and which principles guide them.
Difference One: What They Explore
Prototypes explore implementation details. Will you use an SQL or NoSQL backend? Quickly mock them both up to make a comparison. Can you even supply 10,000 whoozits to the main server on a daily basis? Whip up a little script and give it a shot.
Tracer bullets explore feasibility of the solution. Once you know the implementation details, pick one self-contained component, and give it a spin. Building a project management app? Single out one piece, like todo lists, and shoot at that.
In product development, you want to iterate as fast as possible, so you should start shooting quickly to see if you’re hitting anything. The “tracer bullets” are shareholder feedback!
Difference Two: Principles
The main principle guiding prototypes is “git ‘er done”. It’s quick, it’s dirty, it produces a result (usually information) and gets thrown away. Don’t add anything that gets in the way: get the information and get out.
The main principles guiding tracer bullets are completeness and simplicity. The reason for simplicity is straightforward: you want to see results quickly. Completeness is slightly trickier. It is an acknowledgement of reality: once you have a product that “works”, you must immediately put your efforts elsewhere. If the product is shoddy, or lacks documentation, or took shortcuts, you will be living with those flaws for a long time. Make it right the first time!
You may note there’s a lot of synergy between the idea of a complete tracer bullet and the other Pragmatic Programmer’s idea of “No Broken Windows”.
Benefits
Both prototypes and tracer bullets provide information that will guide the development of a new undertaking. Both emphasize focus to get results quickly. Prototypes allow you to explore the unknowns of implementation, while tracer bullets allow you to explore the unknowns of feasibility. In any normal project, you will probably switch back and forth between the two methodologies as you progress. Just keep in mind what they are good for, and use them appropriately!