Sponsored Link •
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 authored Programming 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:
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.