Recently, I've joined the Structre and Interpretation of Computer Programs (SICP) London meetup. The meetup is run as a coding dojo switching pairs for each problem from the SICP book. To support study of this book, there are some great lectures on the MIT Open Courseware website.
Keeping in mind these lectures were arranged for Hewlett-Packard in 1986, this section stood out. By the way, these comments by Hal Abelson are during a discussion about creating a data abstraction for rational numbers (and don't worry about who George is). The full transcript is available with the MIT course.
But the real issue is that you might not be able to decide at the moment you're worrying about these rational numbers. See, in general, as systems designers, you're forced with the necessity to make decisions about how you're going to do things, and in general, the way you'd like to retain flexibility is to never make up your mind about anything until you're forced to do it.
The problem is, there's a very, very narrow line between deferring decisions and outright procrastination. So you'd like to make progress, but also at the same time, never be bound by the consequences of your decisions. Data abstraction's one way of doing this. What we did is we used wishful thinking. See, we gave a name to the decision. We said, make-RAT, numerator, and denominator will stand for however it's going to be done, and however it's going to be done is George's problem.
But really, what that was doing is giving a name to the decision of how we're going to do it, and then continuing as if we made the decision. And then eventually, when we really wanted it to work, coming back and facing what we really had to do. And in fact, we'll see a couple times from now that you may never have to choose any particular representation, ever, ever. Anyway, that's a very powerful design technique. It's the key to the reason people use data abstraction. And we're going to see that idea again and again. Let's stop for questions.
AUDIENCE: What does this decision making through abstraction layers do to the axiom of do all your design before any of your code?
PROFESSOR: Well, that's someone's axiom, and I bet that's the axiom of someone who hasn't implemented very large computer systems very much. I said that computer science is a lot like magic, and it's sort of good that it's like magic. There's a bad part of computer science that's a lot like religion. And in general, I think people who really believe that you design everything before you implement it basically are people who haven't designed very many things.
The real power is that you can pretend that you've made the decision and then later on figure out which one is right, which decision you ought to have made. And when you can do that, you have the best of both worlds.
This is such a clear explanation for so many parts of good software design. In a couple of minutes, Prof. Abelson goes to the heart of modular design, abstraction layers, deferring design decisions, and iterative development practice. Just goes to show that the proper way to do this hasn't changed in a while (even though it sometimes is packaged differently).