Are companies Agile enough? The tracer bullet approach
As a software engineer, I easily find myself in the middle of different projects and I’m quite surprised that most of them always fall in the same error.
Words as agile, SCRUM and prototyping are frequently used, but not applied as they should.
What’s the error I’m talking about?
An in advance massive planning, without adapting the plan to what’s currently happening.
Creating stories and working in sprints doesn’t mean you’re agile.
What makes agile being agile is the constant adaptation to change.
Of course, planning is still fundamental but it doesn’t mean that we have to blindly stick to it. But that’s too easy to say when you’re not in the middle of development with everything planned ahead, right? In that situation most of the companies just stick to the plan: there’s a product to be delivered!
What’s The Main Ingredient to deliver a product that easily adapts to change?
Tracer bullets.
What the heck I’m talking about? Let’s clarify it with an example:
There are two ways to fire a machine gun in the dark. You can find out exactly where your target is, the environmental conditions, the specifications of bullets and gun and how they combine together. Then, do all the calculation, shoot and hope that your bullets land close to the target. Or you can use tracer bullets. Tracer bullets leave a pyrotechnic trail from the gun to whatever they it, giving an instant feedback and let you adjust the aim for the real bullet.
Especially if you have limited bullets, you would always fire the tracer bullets first to emulate as close as possible what will happen with the real bullet to then shoot it.
With this in mind, let’s now switch to companies, projects and programming. Stop and think a moment about that: which type of bullets are always shoot first?
The analogy of a new project compared to a machine gun shooting in the dark is quite right:
- projects usually consist in something that has not been built before, basically you’re trying to hit a target in the dark
- requirements and environment will be vague and susceptible to change, like the blowing wind or the usury of your gun
- there are way too unknown, like new technologies, team and languages.
What can we get from this?
Do not use all of your code bullets from the start…
use tracer code instead.
Tracer code allows you to spot potential problems in a very early stage
Imagine that you want to build a new online platform which has different modules: A, B and C. Entering the platform, the module A has functions which get some data and whose outputs are used by module B. At the same time, the user needs a place to access both data from modules A and B, that’s the parent module C.
You never did something like this before, it’s a complete shot in the dark.
That’s the perfect opportunity to use tracer code. Instead of building each module fully and then start testing the integration between them, create a skeleton of each module and pick the simplest feature that you planned.
After picking it, make it simpler and build it!
You will end up with a working skeleton of your platform. Now, just stop. Stop, think a second and compare what you have with what you would have without using tracer bullets: probably nothing, fully functional features need more time to be developed (and they still need to be integrated, good luck!).
The difference here is that you have something: you can show it, get feedback and, as with tracer bullets, you can check how close to the target you are, adjusting the aim if necessary. Once you’re on target, adding functionality is easy.
Is this the same as prototyping?
Absolutely not.
The biggest difference of prototyping vs the tracer bullet approach is that the prototype goal is to explore specific aspects of the final system. A prototype should be thrown away as the goal is reached, while the tracer code is developed to stay and to be a flexible foundation for the new features and updated requirements popped out, probably thanks to the new findings coming from user feedback and during development.
A prototype can simply be a bunch of post-its, some spaghetti code in a random programming language just to test an hypothesis.
The tracer code is your final code, and it’s gonna be your final product always ready for the next incoming change.
Start to use tracer bullets now, don’t finish all your bullets first.
Enjoyed the article? Press and hold the clap icon 👏 if you did and share it if you think it would be useful to someone else. Feel free to give any feedback or comment below👇🏻, I’m eager to to know what you think!
Credits
The tracer bullet approach and part of this article are from the book “The Pragmatic Programmer”, written by Andrew Hunt and David Thomas. If you are a software engineer continually looking to improve yourself, you should definitely check it out.
