Tracer Bullet Development
Tracer Bullet Development (TBD) is a metaphor for software development based on the idea of instant, real-time feedback under actual conditions. Tracer bullets are special ammunition that visually trace their path to the target; gunners can adjust their aim in real-time, under actual conditions, to accurately hit their targets (especially if the target is in motion). TBD provides a set of techniques that allow us the same rapid adjustments in software.
- Users often demand sweeping changes after lengthy and expensive development
- Technical surprises derail the project late in the game
- Clean designs quickly devolve into spaghetti code or a “big ball of mud”
- Areas of the code have grown dangerously intertwined; it’s difficult to touch any part of the system without breaking something unexpectedly
- APIs and architecture seem to always be in flux, never quite right and requiring constant rewrites
Tracer Bullet Development:
- Provides a generic architecture early
- Outlines your overall system early
- Forces clean demarcations across layers
- Requires test automation early in the project life cycle when it’s easiest to implement
- Enables cooperating teams or individuals to cleanly work in parallel
Tracer Bullet slices of functionality will move through the system, shining a light on the dark corners and overlooked details. After the technical bits have been ironed out and are working, you’ll have a system (thanks to all the canned data) that appears to be working (even though it isn’t) and can be demonstrated to your customer. You’ve now skipped far ahead of a typical software project and you can ask your customer if the workflow makes sense long before you complete the rest of the system.
- You can demonstrate one feature in an arbitrarily large system within a day or two (100pts)
- Coding is mostly refinement, not from scratch (50pts)
- It takes weeks or longer to prototype or demonstrate a feature (-100pts)
- Coding is always from scratch, with no existing work to hang it on (-100pts)
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this practice:
- Find a place to experiment with TDB, even if it’s for a new feature in an existing system, or for an entirely new project
- Follow the steps to use TBD below. Remember that the first level is purely skeletal and does not offer any real functionality.
- Does it feel like the code is growing steadily, without a lot of backtracking and rework?
- Are users happier to see something interactive earlier in the process?
What Does it Look like?
Tracer Bullet Development is based on the idea of taking some single feature, single action, single thread of workflow, and implementing it all the way through the system under construction: from UI to database, passing through any middle layers right from the very first implementation on the first day. None of these layers need to be fully functional, but they must be present. Think of it as an extended “Hello, World!” programming exercise.
Here is an approximate list of steps you’d follow to write software using TDB:
- Define the major system objects. Usually UI, server, logic bits, and database abstraction layer.
- Define the flow of data through these system objects
- Code your APIs and their return values to achieve that flow
- Document expected usage of these APIs with unit tests
- Add just enough canned data (aka dummy data, fake data, hard coded data) to each API so it “runs”. Remember, it’s only “Hello, world!”
- Incrementally replace the canned data with real functionality
- Refactor your code, refine your system objects, and continue to do so until you’re done
In the spirit of getting fast feedback and growing code, you want to use a TBD approach to all development.
This workflow forces you to create vertical slices of functionality. These metaphorical bullets move from the front end code all the way through the lowest layers of the system. This allows your team to quickly understand which architectural and technical decisions will work, and which may not work out the way you expected.
It also forces different groups to talk! This is absolutely vital to the success of larger projects, especially in a larger company where functionality might be implemented across teams. You must find a way to communicate in an unambiguous way to other groups of people. History has proven that the written word is insufficient. Slides and pictures also fall far short. However, working code with tests is a great to communicate to other developers.
You’re doing it wrong if:
- First version of the system takes more than a day to put together
- Add too much real functionality too soon
- Build in real functionality before getting feedback
- You don’t show the canned demo to actual users for feedback
How To Fail Spectacularly
- Omit a layer/piece thinking you’ll “add it later”
- Ship the prototype
- Ignore user feedback
←Prev (Automate Everything)(Write It Down) Next→