I was recently reading The Pragmatic Programmer for the first time and I came across the concept of Tracer Bullets. I realized that I had coded according to this model in the past and just kind of filed the way I was working away in my brain as "agile".

They only give one example of where they had used it in the past. The way the situation was identified to be a good candidate for Tracer Bullets was

There were many unknowns, and many different environments, and no one was too sure how the GUI should behave.

That kind of seems like the way a huge number of projects start, especially when you're working with non-technical people on a typical line of business app for a hedge fund (as an example).

I used it because it simply felt right, without really knowing what it was called or having it explained to me. I knew that if I tried to get everyone in a room and got them to spec everything (or at least some things) up front it would be a complete disaster, but again that's a feel kind of thing...

Can anyone come up with some more concrete criteria for when this model might be the way to go?

  • Rememeber tracers work both ways
    – MattyD
    Nov 15, 2011 at 0:51

3 Answers 3


You need to have a project where you can get an idea about if you're on the right track with only a small subset of functionality. Generally this is possible for things like basic GUI design, but is hard with things where the results are unknown -- e.g. if you are designing a data mining app and the shape of the tool will depend on what sort of patterns occur in your data.

You also need to be in a situation where you can afford to iterate many times. This costs time and development (and of course may be beneficial if you subscribe to agile development processes), but more difficult is the cost in terms of exposure to users. Users will quickly get exhausted if you show them too many designs and the quality of your feedback will go way down. So you either need a large user pool, or to pick your (micro)releases carefully.

  • 1
    I don't agree with the second paragraph. In my view, Tracer Bullets development helps you create an architecture that works for your project. No feedback from the user is needed, TBD helps the developpers to architect the internals of the product, not the user visible features.
    – barjak
    Aug 30, 2011 at 20:14

I'd say that there is really only one basic factor that determines how useful a Tracer Bullet approach is: the number and scope of uncertainties in the architecture and design of the application.

Because the primary (if not only) goal of the technique is to clear up such uncertainties, you will not benefit much from it if you don't have any or they don't concern the architecture or design. A greenfield project with no architectural constraints is a typical example for when starting with a Tracer Bullet is almost the only sensible thing to do, whereas a for a mature project with some new features to implement it would probably be a waste of time (even though there may be uncertainties regarding the requirements, clearing those up is more the domain of general agile or iterative development).


I came across the concept of Tracer Bullet development in the book Ship It!, edited by the pragmatic programmers.

I guess that in your question, you are referring to the book The Pragmatic Programmer: From Journeyman to Master. I haven't read that one, and I don't know how TBD is presented there. In Ship It!, there is one chapter (20 pages), dedicated to TBD. In particular, they talk about their experience with a concrete example : a datamining application for a biotech company. Basically, they explain that having nice abstraction layers (designed using TBD) helped them remove the performance bottlenecks one by one, by parellelizing each layer.

In my view, TBD is two things :

  • Create a software architecture by isolating the system objects, and let the developpers collaborate to define the interfaces between these system objects
  • Use mock objects to ensure the architecture is sustainable (test the architecture early)

I think the first point is a very good way to architect a software, no matter what. The second point is interresting : it can potentially prevent a complete rewrite of a project due to an initial architecture that doesn't work in practice.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.