Tracer Bullet Development
Summary
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.
Pain Points
- 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
Benefits
- 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
Assessment
- You can demonstrate one feature in an arbitrarily large system within a day or two (Major Boost)
- Coding is mostly refinement, not from scratch (Boost)
- It takes weeks or longer to prototype or demonstrate a feature (Setback)
- Coding is always from scratch, with no existing work to hang it on (Significant Setback)
Application
✓ Critical ❑ Helpful ❑ Experimental
Adoption Experiment
Steps to first adopt this habit:
Setup
- 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
Trial
- Follow the steps to use TBD below. Remember that the first level is purely skeletal and does not offer any real functionality.
Evaluate Feedback
- 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 work flow, 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 work flow 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 way to communicate to other developers and with users.
Tracer bullets were first introduced in The Pragmatic Programmer (missing reference).
Warning Signs
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
- Separate teams build entire layers with a plan to integrate it all “later”
How To Fail Spectacularly
- Build in layers, often with separate teams
- Omit a layer from the Tracer thinking you’ll “add it later”
- Ignore user feedback
←Prev (Automate Build Pipelines)(Write It Down) Next→
