The practice of Tracer Bullet Development (TBD) lets you see where things are headed as soon as you start and helps you aim continuously long before you’re done.
A process must answer the following:
- Does it work for you?
- Is it sustainable?
Tip 19: The goal is software, not compliance
How Does It Work?
You create an end-to-end working system when you use TBD, but the system components are all hollow objects. You write code for all the big pieces of your system, but the objects aren’t doing any work. Your database access layer returns data, but it’s really returning canned data, not data from a database.
Identify the major parts of your project, and divide your product into blocks of related functionality. For example, you might have blocks called client, web server, and database layer. Define the information that the blocks need to exchange and document the information with method signatures. These areas of layer interactions are called interfaces. Give each block to a different developer, team of developers, or corner of your mind (if you’re working solo). Write just enough code to make everything look as if it works. Think of it as an entire application of Mock Objects. With this thin, skeletal framework in place, you can begin to fill in the real logic inside each block. Finally, and most importantly remember that interfaces will change and evolve throughout the project. Your first shot will always miss the target, so be flexible and adjust your aim at any point. When another team approaches you for new interfaces, or to make changes to existing ones, go ahead and make the change. This is software, after all.
I've done a form of this and we called it "spiking the architecture". I found it to be useful because you can't anticipate some issues until you starting manipulating code. I don't think "big bang" development works so TBD might be a useful tool for me.