Summary
Pragmatic Programmers Andy Hunt and Dave Thomas talk with Bill Venners about the importance of getting feedback during development by firing tracer bullets and building prototypes.
Andy Hunt and Dave Thomas are the Pragmatic Programmers, recognized internationally as experts in the development of high-quality software. Their best-selling book of software best practices, The Pragmatic Programmer: From Journeyman to Master (Addison-Wesley, 1999), is filled with practical advice on a wide range of software development issues. They also authoredProgramming Ruby: A Pragmatic Programmer's Guide (Addison-Wesley, 2000), and helped to write the now famous Agile Manifesto.
In this interview, which is being published in ten weekly installments, Andy Hunt and Dave Thomas discuss many aspects of software development:
Tracer Bullets
Bill Venners: In your book, The Pragmatic Programmer, you suggest that programmers fire "tracer bullets." What are tracer bullets? And what am I trading off by using tracer bullets versus "specifying the system to death," as you put it in the book.
Dave Thomas: The idea of tracer bullets comes obviously from gunnery artillery. In the heavy artillery days, you would take your gun position, your target position, the wind, temperature, elevation, and other factors, and feed that into a firing table. You would get a solution that said to aim your gun at this angle and elevation, and fire. And you'd fire your gun and hope that your shell landed somewhere close to your target.
An alternative to that approach is to use tracer bullets. If your target is moving, or if you don't know all the factors,you use tracer bullets—little phosphorous rounds intermixed with real rounds in your gun. As you fire, you can actually see the tracer bullets. And where they are landing is where the actual bullets are landing. If you're not quite on target—because you can see if you're not on target—you can adjust your position.
Andy Hunt: Dynamically, in real time, under real conditions.
Dave Thomas: The software analog to firing heavy artillery by calculating everything up front is saying, "I'm going to specify everything up front, feed that to the coders, and hope what comes out the other end is close to my target." Instead, the tracer bullet analogy says, "Let's try and produce something really early on that we can actually give to the user to see how close we will be to the target. As time goes on, we can adjust our aim slightly by seeing where we are in relation to our user's target." You're looking at small iterations, skeleton code, which is non-functional, but enough of an application to show people how it's going to hang together.
Basically, it all comes down to feedback. The more quickly you can get feedback, the less change you need to get back on target.
Andy Hunt: Having said that, there are times when either approach is appropriate. You might think it sounds silly taking the big guns and firing computers approach. Well, if you're shelling a city, which isn't moving, that's a pretty good way to go. If you're writing software for the space shuttle, or any kind of environment where you really know all the requirements up front and they're not going to change, that's probably the cheapest way to do it. And there are some environments where that is the case. Not many, but that actually does happen. If you're shooting at something that's not a city, something that's moving, then you want to get that rapid feedback.
Dave Thomas: Tying in to what Andy said earlier (In Part III, Good Enough Software) about software having a Heisenberg effect, where delivering the software changes the user's perception of the requirements, almost by definition, your target is moving. The sheer act of delivering the first release is going to make the user realize, "Oh, that's not quite what I wanted."
Andy Hunt: Or even worse yet, "Oh, that's exactly what I wanted. But now having seen that, I've changed my mind. I've learned. I'd now like to do this instead, or this in addition." Just by introducing the software, you've changed the rules of the game. Now the user can see more possibilities that they weren't aware of before. The user will say, "Oh, if you can do that. What I'd really like is if you could do this." And there is no way to predict that up front.
Starting with a Skeleton Application
Bill Venners: You say in your book, "In tracer code development, developers tackle use cases one by one." What is a use case, and why do you recommend that we do tracer bullets in use case chunks?
Andy Hunt: Central to tracer bullet development is the idea of a skeleton application, in which one thin line of execution goes end to end. In a skeleton application, you have some bit of functionality—even if it's just the equivalent of "Hello, world!"—that goes all the way from the UI, through business logic, through whatever else is in the middle, all the way to a database. It may do nothing more than put a checkbox value into the database as a Boolean. Whatever the skeleton application does, it does end to end, skeletally thin.
From the skeleton application forward, you might start adding one feature at a time, where each feature implements one use case. You implement the feature, go all the way through, and see if it hangs together. As you steadily grow your application, one feature at a time—this is where tracer bullets come in—you may realize, you're off by a little bit. Well, you still don't have that much code. It's still easier to adjust it and fix your aim. As you grow the application fatter and fatter over time, it will be increasingly harder and harder to make gross changes. But you'll also be getting smarter as the project progresses, because you are firing tracer bullets and getting feedback. So when the requirements are more volatile, the code is easiest to change. Later the code does become harder to change, but by then you know more and less change is required.
--From http://www.artima.com/intv/tracer.html.
PS: what is prototype programming? To be continued...