Sponsored Link •
Pragmatic Programmers Andy Hunt and Dave Thomas talk with Bill Venners about 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.
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:
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 .