What are some good criteria for using Tracer Bullets?

Question

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?

Answer 1

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.