Sponsored Link •
Pragmatic Programmers Andy Hunt and Dave Thomas talk with Bill Venners about the importance of programming defensively against your own and other's mistakes, of crashing near the cause, and understanding the proper use assertions.
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 programming defensively against the potential mistakes of others, and against our own mistakes. Why shouldn't I trust myself or others, and what should I do about it?
Dave Thomas: The simple answer to that is, when was the last time you or I or anyone else was perfect? We know that we make mistakes all the time. Our compilers, our computers, our applications, and our users tell us we make mistakes. So why shouldn't we learn that lesson of history, and account for mistakes up front?
Andy Hunt: There is an interesting parallel in woodworking, which I do as a hobby. A woodworking magazine recently had an article suggesting that how a woodworker deals with mistakes is what differentiates a master from someone who's not. Everyone makes mistakes: You cut something too short; There's a crack in the board; Something goes wrong. Do you have the skill to work with the mistake, to get beyond it? Or are you just dead in the water and you have to start over?
Dave Thomas: That analogy is a good one. When you're working with wood and you make a mistake, you have to decide, "Do I go on with this? Or do I stop and go way back, fix the problem, and start again?"
Andy Hunt: Is it salvageable?
Dave Thomas: Right. And that's something developers would do well to think about.
Andy Hunt: You can look at it from the other way around too. Once you cut a piece of wood too short, it's really hard to grow it back long again. That's a bad thing. Once you've done something to a piece of code where you've really got to start over, that's where you just have to bite the bullet and really start over. You can't patch it. But programmers don't like to make that decision. I think most programmers prefer to say, "No, I'm sure I can just patch around it." And that's equivalent to trying to glue that little bit of extra stuff on the end of a piece of wood. It just doesn't work out real well. You've got to know when to cut your losses.
Dave Thomas: And just to throw in another side of the same equation: as well as this attitude of, "I've worked real hard on this I'm not going to throw it away," is a complementary attitude. Quite often if you show programmers someone else's code, and that code has a single bug in it, their response will be, "Oh, I have to rewrite this." So you have to be good at working out what the problem is and what you need to do about it.
Andy Hunt: You have to figure out what is the appropriate level of repair.
Bill Venners: How do I decide how much to check myself? It takes time to write unit tests. It takes time to do design by contract. How paranoid should I be about my own code?
Dave Thomas: You use feedback. To start off, you choose a level that sounds reasonable. You use it, and you ask, "Is this level finding most problems?" If it is, then you say, "Maybe I could cut it back a bit." If you cut back and the situation gets worse, you go back up again. If you're doing some unit testing and a few asserts and still a whole lot of bugs are getting through that you're embarrassed about, then you're not doing enough. It's not one of the prescription things where you say, "A two year programmer has to do 80% unit test coverage." It's what works for you.
Andy Hunt: It comes down to feedback. If you think, "I'm doing great unit testing. I couldn't do more. I'm really at the top of my game." And yet you're getting a flood of bug reports on your code back from Quality Assurance (QA) or users, you probably need to do a bit more.