A Conversation with Andy Hunt and Dave Thomas, Part III

---

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:

• In Part I. Don't Live with Broken Windows, they discuss the importance of software craftsmanship and the importance of staying on top of the small problems in your projects.
• In Part II. Orthogonality and the DRY Principle, they discuss the importance of keeping your system orthogonal, and the real meaning the DRY, or Don't Repeat Yourself, principle.
• In this installment, they discuss the myth of bug-free software, the importance of specifying level of quality as a system requirement, and the need for every team member to inject quality throughout the development cycle.

The Myth of Bug-Free Software

Bill Venners: You say in your book, The Pragmatic Programmer, that "the real world won't let us produce much that's perfect, particularly not bug-free software." Why is that?

Andy Hunt: It's economics. Look at some very solidly crafted code, for example, the space shuttle. The cost per line of code for the space shuttle is something like a thousand dollars per line. It's so expensive because of the amount of care that goes into specifying the code, reviewing the code, the whole process they use. It is understandable that if you're shooting up billion dollar spacecraft with human lives at stake, you're going to put a little bit of care into that software. But everything has its cost.

The space program has had its share of bugs. Various Mars probes have flown off into the weeds. Rockets have crashed. But nevertheless the space program has a pretty good track record on software quality, but at tremendous cost. You can't spend a thousand dollars per line of code in a dot com or even most major corporations. You simply can't afford that.

People tend to think software is free, because it has no real-world presence. Software is not substantial like disk drives or automobiles—it is just people typing away at a keyboard. So, therefore, software must be free. But it's not.

Dave Thomas: Aside from economics, it is also very arrogant to assume you know what the user wants. You may say, "Each one of my programs is a testament to me. Therefore, I'm going to make each program perfect, so it reflects well on me." But the users may not want to spend the money, or invest the time, to achieve that perfection. For all you know there may be an expiring need. If the users don't get the software within X number of weeks, there's no point in having it. There's no point in writing the software for the polling booths in Florida, for example, if it's not available at the time of the election. So you have to be prepared to make the compromises.

Andy Hunt: Also, despite what the users say, it's very hard to judge what's actually important to them, because they themselves may not know. You may collect requirements and interview users. You may be certain that a particular feature is the most important. You put all your work into that important feature and ignore another minor feature that the user didn't seem to care much about. But later, you find out that in practice the users use this important feature only once every six months. The minor feature that you kind of ignored, they use six times a day. Now that's a huge problem.

What features are most important is not always clear up front. It's not even always clear to users. You need to be prepared to rock and roll and be flexible a bit. There's a kind of Heisenberg effect as you put a system into production and real users start using it. The act of introducing the system changes how the users work. It's almost impossible up front to be sure you know what the user wants, and then implement that perfectly. The very act of introducing your software into the user's world changes the game.

Dave Thomas: There is also a secondary impact to assuming you can actually write bug-free software. If you go in assuming that you can produce bug-free software, that attitude changes how you write the software. You tend to get arrogant, or at least complacent, about the actual code that you write. You'll say, "My code is going to be bug free. Therefore, I don't have to worry about this particular condition or that particular condition." The reality is that your code not going to be bug free, because you don't control the entire environment .

Specifying Quality as a Requirement

Bill Venners: You also say in your book, "The quality of the system you produce should be specified as part of the system requirements." Why is that?

Dave Thomas: You say to a user, "You can have this software in two months. We anticipate it will be perfectly usable, though it may have a few rough edges. Or, we can polish it to perfection, and you can have it in seven years. Which would you prefer?" I think the user should get to make that choice. As a result, it is actually a part of the user's requirements to say what level of quality they want delivered.

Andy Hunt: And that's not an easy question. In the space shuttle, for instance, the correct answer probably is seven years. In the commercial sector it probably isn't.

Knowing When to Stop

Bill Venners: You say, "Don't spoil a perfectly good program by over-embellishment and over-refinement." How do I know when to stop?

Dave Thomas: Fundamentally, you know when to stop when the user says stop. One of the mistakes that a lot of developers seem to make is to develop in a vacuum. They'll have a project plan that says nine months from now we'll deliver something. Nine months later—or two years, whatever it ends up being—they deliver something and assume the project's gone away. But that approach is never going to work effectively.

If you work with the user more closely, if you work interactively with the user on a daily or weekly basis, then that user's going to be able to tell you when it's time to stop. You don't let the programmers keep adding features simply because they feel like it would be a good idea. Adding features should be a user decision, not a programmer decision.

Andy Hunt: In fact you can get the problem both ways. Sometimes programmers will want to keep piling features on after the program's done, but more often I think you get the opposite problem. Once the programmers have done most of what the user wants, they stop. They stop too early, when the program doesn't necessarily meet the user's needs. You can stop too early, or too late. And in both cases, the answer is feedback. As Dave said, if you work very closely with the user, you've got a much better way of judging if you're done yet.

Quality is What You Do, Not What You Measure

Bill Venners: You said, "Some methodologies have a quality officer, someone to whom the team delegates the responsibility for quality. This is clearly ridiculous. Quality can only come from the individual contributions of the team members." Why?

Dave Thomas: Because the notion of a quality officer implies that the rest of the team is out there to undermine quality. The quality officer is a policeman whose job is to catch and slap the wrists of the naughty little programmers, to send them back and tell them to do it again. Quality is not something you test after the fact. Quality is something you do all the time as you're actually doing the development. It's every individual's job to inject quality into what they're doing. Now you may have a coach or someone who can help you with the details of achieving quality, and you certainly want some kind of QA testing and acceptance testing. But you don't produce quality by installing a quality officer, ticking the quality checkbox and assuming you have quality taken care of because the quality officer is out there.

Andy Hunt: Having a quality officer is kind of like having a breathing officer.

Next Week

Come back Monday, March 24 for Part IV of this conversation with Pragmatic Programmers Andy Hunt and Dave Thomas. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Resources

Andy Hunt and Dave Thomas are authors of The Pragmatic Programmer, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/020161622X/

The Pragmatic Programmer's home page is here:
http://www.pragmaticprogrammer.com/

Dave Thomas was not the first person I've interviewed who mentioned the arcade game Whack-a-Mole. James Gosling also called upon the versatile Whack-a-Mole metaphor while pointing out that it is sometimes hard in engineering to know if you've solved a problem or moved it:
http://www.artima.com/intv/gosling34.html

The Agile Manifesto is here:
http://agilemanifesto.org/

Ward's Wiki, the first WikiWikiWeb, created by Ward Cunningham, is here:
http://c2.com/cgi/wiki?WelcomeVisitors

A great article about the space shuttle software, They Write the Right Stuff:
http://www.fastcompany.com/online/06/writestuff.html

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.