That’s what you want to avoid. You always want to use the right tool for the job in the right context. So I’m a fan of test-first development. I don’t always do it. It’s not always appropriate.
It’s the same with anything else. You know, pair programming or even big up-front design. There are some cases where that’s actually the best way to go. There are more cases where it’s not, but every technique has its place somewhere in the world in some context.
Ed: Several of the people I’ve interviewed had some things to say about the intrinsic value of the tests in a software system. Do you have anything to say about that?
Andy: Some venture capitalist type once asked me where the real value was in a software system, and he was thinking it was in the source code and we were trying to convince him that, no, that’s actually not the case.
If you think about it, the most valuable part of a well-constructed software system is not the code itself. It’s the unit tests. That actually defines the behavior of the system. It is a functional working specification. In terms of intellectual property, that’s actually far more valuable, ’cause given that you could re-create the source code in any number of ways, the source code becomes far more disposable when you think of it that way.
Ed: Right. Isn’t it the case that the unit tests represent a very, very specific and strongly constrained set of requirements?
Andy: Yes, absolutely, and whatever you choose to do that happens to fulfill them, that’s a much larger set. There’s the system that happened to be written, but that doesn’t preclude writing a completely different one that would fulfill the same requirements and provably so.
Ed: Yes, it’s proven that automated testing is a bulwark against human nature. But here’s a situation often faced by human programmers. Let’s say it’s late at night, you’re up against a deadline, and you’re desperate to get a piece of code working and checked in. You come to a situation where you’re faced with the choice between doing the right thing and doing the quick thing. How do you motivate yourself to do the right thing?
Andy: I think Douglas Adams’ advice is real key there: “Don’t panic.” This is the number one place where we get into trouble as developers. We feel the crushing pressure of the deadline and we do something stupid because it’s expedient. It’s like gambling or Powerball. Every so often you win the $5 prize and go, “Woo-hoo. There’s some success to this.” Every so often you will take that cheap shortcut and it works out. You don’t get caught, you get away with it. You think, “Hey, this is great.” And then, of course, you take the next shortcut and the whole thing goes tits up and you’re just totally blown.