When to use Tracer Code rather Prototyping?

Question

I am reading the book The Pragmatic Programmer and read about the Tracer Code and Prototyping, but I don't understood when to use Tracer Code instead of Prototyping.

As I understood about Tracer Code, I try to hit the target implementing a code that the customer can test in practice and provide me feedback in real time, and the implemented code is a part of the final system. When I do Tracer Code it must be as a standard project with all good practices and a architecture(a skeleton, not all implemented). However Prototyping is a disposable code where I use it only to learn requirements from customer. After learning from the customer I must throw away the prototype.

When I must use Tracer Code instead of Prototyping? Can I use both?

Answer 1

I no longer have a copy of the first edition of The Pragmatic Programmer, so I'm basing this answer on the contents of the second (20th Anniversary) edition. My understanding is that much of the content remains the same, but has been refined based on changes in the last 20 years.

The use of "prototyping" in The Pragmatic Programmer (such as in Topic 13 Prototypes and Post-it Notes) is constrained to throw-away prototyping. Tracer bullets are closer to evolutionary prototyping or evolutionary design techniques. The idea behind tracer bullets is to get a working version in front of stakeholders and obtain feedback on that version without throwing it away.

The final paragraph in the Tracer Bullet chapter explains it succinctly:

Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system.

It is possible to use both together, for different parts of the system. They are complementary techniques that help to figure out what needs to be built and ensure that the effort is being spent on building the right thing. The use of throw-away prototyping versus tracer bullets (or evolutionary prototyping) depends on the context.