#begin
The next section an about the concept of tracer bullets. This has become a pretty important analogy in the software architecture space since I keep hearing people mention it in podcasts, blogs or conference talks. I’ve described what this means before but let’s quickly repeat; Tracer bullets are special kinds of phosphorus bullets that are loaded into ammo belts. These light up when fired and thus the bad boy firing the machine gun can visually determine where the bullets are landing. This way he’s better able to adjust his aim and hit the target.
So how does this relate to software? Well, particularly when you are building something new, that has not been built before. Like these gunners, you need to be able to see in the dark. Requirements might be vague, algorithms or even the programming language, unknown, unfamiliar libraries and so forth. Andrew and David say that the classic response is to “specify the project to death”, which is a reference to the waterfall method I suppose. However, pragmatic programmers use tracer bullets to determine the best possible architecture.
They say that tracer bullets work because they operate in the same environment and under the same constraints as the real bullets. Most importantly, they provide immediate feedback, and for a practical point of view, it’s a cheap solution. So in a software context we need something that gives the same effect. Something to determine the final system quickly, visibly and repeatably.
Next they tell a story of some client server application they wrote and how they used tracer bullets to determine the architecture. The moral of this story boils down to, after prototyping, when you proved something works, you need to create an app that has all the basics ready for development. This really makes me think about the “walking skeleton” metaphor from a book called Growing-Object-Oriented-Software-Guided-Tests by Steve Freeman and Nat Pryce. This is a really, really great, deep technical book about using TDD as a driver for software design. I strongly encourage you to read it if you are into TDD or simply want to know what the fuzz of TDD is all about.
But in this book they mention that, it is very difficult to start right out of the gate with TDD. Some things are just very, very hard to test; like bootstrapping your application. So creating a very simple app, with just 1 end-to-end test that checks if for example a button click triggers the right function in your repository class will test all the layers of your application. This way you have a starting point to develop your app, hence the name “walking skeleton”. I really like this approach, and it is one I take very, very often.
Next, Andrew and David mention something interesting and I quote: “Tracer code is not disposable: you write it for keeps. It contains all the error checking, structuring, documentation and self-checking that any piece of production code has. It’s simply not fully functional. However, once you have achieved an end-to-end connection among the components of your system, you can check how close to the target you are, adjusting if necessary. Once you are on target, adding functionality is easy.”
So this is exactly what I meant with the walking skeleton approach. But David and Andrew take it a step further by saying that tracer development is never finished. There will always be changes and function to add so it’s an incremental approach. And I fully agree, I think you can make tiny little skeletons as well. So for each new feature you setup the skeleton for and then fill in the details. I really like this.
So tracer code has a couple of advantages. First of all is that users get to see something working early. This is important in an agile context since you can adjust your strategy early and accordingly. Plus, users will not be disappointed by the lack of functionally, they will only see the potential of what it might become. So it keeps your users happy.
Another advantage is that developers build themselves a structure to work in. If you have a skeleton for all the end-to-end interactions of your system, you have guidelines and design decisions to work from. Developers don’t need to come up with all kinds of tricks to connect components by themselves. They just follow the tracer code all the way.
You also have an integration platform since the system is connected end-to-end. You can plug in new code as you see fit, or rip things out. But it will also help you to demonstrate functionality to customers or your superiors. I want to mention here also, that your skeleton might just be logging to the console to prove it’s working. Or maybe just running a bunch of unit-tests. As long as it proves the functionality in an end-to-end way you should be able to “sell” it as well deserved progress. Speaking about progress, tracer code is the perfect way to feel like you are going into the right direction, but I think that is pretty clear by now.
However, we also need to recognize that, not all tracer bullets will hit their target. So you really need to adjust your aim until you are on target. That’s the entire point of tracer code. You shouldn’t be surprised if you hit some dead ends. You simply use this approach when you are not 100% certain some design will be sufficient for the problem you are trying to solve. So, when you are off-target a bit, adjust. The great thing about tracer code is that it always starts out small, as simply a skeleton. But once you are on target you start to fill in the details. So adjusting will not take much effort if done right.
Next they rightly mention the difference between tracer code and prototyping and yes, this is a valid argument. Tracer bullets is meant to be used for production purposes and explore solutions. Prototyping is meant to find out if things are even remotely possible, you throw all your disciplines out of the window, hack something together quickly, cut major corners just to prove something is feasible. Prototypes are often throw-away projects. I will repeat this, because I’ve made this mistake before; Prototypes are often throw-away projects. So if you made hacky prototype your managers must understand that you throw it away and start over from scratch since if you take on the technical dept from the prototype right from the start, it’s gonna be dirty very, very fast.
Tracer code addresses a different problem; You need to know how the application as a whole hangs together. This is a distinct different! As I said before, tracer code is mean for production purposes, not prototyping. Tracer code is lean, but complete and serves as the skeleton of your application. Prototypes are a form of reconnaissance and intelligence gathering that takes place even before tracer bullets are fired! And that’s about everything they have to say about tracer code.
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments