Tracer Bullets, as the name implies helps you trace the trajectory and the position where they hit the target. They are just like the regular bullets except that they have a modified base to contain pyrotechnic charge. This composition burns brightly when fired and allows the shooter to view the projectile. A machine gun usually has one tracer bullet for every 4-5 normal bullets which allow the user to take a better aim at the target. It helps the shooter understand where rest of the bullets are landing. In a nutshell it provides instant feedback and helps to aim right. Thus following the philosophy of Ready, fire, aim.
So how does it apply to the software that we develop? Well, if you notice closely then Agile helps us follow this in a way in which we are showing some constant work and soliciting feedback every few days. Until we show something working the stakeholders are not better equipped to take decisions. Assume that the stakeholders want to build a solution to market the big integration that the product is supposed to do with the market leader CRM solution. They would have some ideas but those might not be concrete enough. There are a few ways of demonstrating how the user story would work.
- Spike – a spike is a quick and dirty implementation to show that the suggested solution would work. It does not follow the laid down architecture and might be done in a different language all together. For example a spike could be done in RoR and then later implemented in Java. These are more like prototypes and are thrown away.
- Research – this has a larger base and might be very theoretical. Research should be time boxed and the results should be good enough to indicate whether a spike or a tracer bullet is required or may be the team needs a different direction all together.
- Tracer Bullet – the tracer bullet is a spike with the current architecture, current technology set, current set of best practices which results in production quality code. It might just be a very narrow implementation of the functionality but is not throw away code. It is of production quality and rest of the iterations can build on this code.
If you are following Agile, I would recommend the tracer bullet approach because you get the benefits of doing a spike and that too which results in production quality code. It would be a narrow implementation of the functionality but would have all the ingredients of the current technology stack. You would be able to gather stakeholder feedback. You do not need to throw away this code and can build on that.
I remember working together with a few esteemed architects who built the E*Trade platform. When we were about to start the project, they mentioned that let us build a “count service”. I am assuming that you would be as lost as I was on what the hell this count service is. People who have worked on the E*Trade platform would be able to relate to this. As it turned out, the count service was a tracer bullet. It was a service that did nothing more than incrementing a counter in the database, however, it was production quality. It made its way through all the layers and came back with the incremented counter. All the code quality specifications were adhered to and the unit tests worked like a charm.
The count service was a production quality code which other developers used to reference and extend.
Hence every sprint should have a scope for tracer bullets. There is a fair chance that stakeholders have some idea about user stories but would like to see something working before they can take decisions. If this is the case then before venturing out by building the entire story, build tracer bullets.
There still might be a need for spikes and lengthy researches for a product but if you want the biggest bang for your buck then get your tracer bullets ready. Which way would you generally like to go with your Agile sprint, spikes or tracer bullets?
