Lazy Decision Making
We recently cleaned out my parents’ garage so that it could be torn down to make room for an intergalactic expressway a storm drain. Amongst the millions of childhood memorabilia was this book, which was the first taste I got of computer programming.
It taught us Apple BASIC, and we used it to program our Apple IIc that had one external drive. We had a bunch of floppies, a few of which we loaded ProDOS onto and toiled away.
If I recall correctly, my older brother was the one who had actually purchased the book (or convinced my parents to buy it for him) so it was ostensibly his, and he assuredly read through the thing quicker than I did, and understood more of it that I did even when I had read most of it. I was, after all, 8 at the time.
But with that book and that computer we set about to write our own games. I still believe that every programmer of my generation gets into computers for the games. I wrote a little game where you could run through computer systems a la Shadowrun, breaking ICE and finding valuable files. I tried to do HiRes graphics, which was why the game never got finished.
This was before I understood anything about design. Not that you could design in BASIC, but still.
What I did was try to figure out everything I would ever need to do, I wrote it down in a big list, and then I started at the top of the list. I wrote the main screen. I wrote the login. I wrote the first bit of navigation into the fake computer system. I got overwhelmed and never returned.
I was following what is now called the Waterfall model, where you spend a whole lot of time figuring out what you’re going to do, and then you write it all down in excruciating detail and make sure that it covers everything, then you check again. Then you check again and start programming.
This model was invented when you programmed with punch cards and had to make sure that everything worked reasonably well the first time. If it didn’t, you’d have to change something, and changing things was nigh impossible, because you can’t just insert a new row on the punch card: it’s cardboard. So you do proofs and flowcharts and loop invariants and whatnot, trying to make sure that when you go to the trouble of making the punch cards, everything works out.
Contrast that with what most programmers do today, which is sometimes referred to as Extreme Programming, XP, Agile Development, or simply Iterative Development. Whatever you call it, you figure out only what the next step is and you program that. Then you test it. Ideally, you write a test for it so that the test can be run by an automated process. Then you move on to the next step.
Developers like this method because they get immediate results (and they do a lot less paperwork). Managers like it because they get lots of feedback (and they do lots less paperwork). Customers like it because it allows the developers to respond to feedback, which means the customer gets something he actually wants, instead of something he kind of wants.
Iterative Developement is part of a larger trend in the computing world toward deciding things later, because later you will have more information with which to make the decision. It’s called Lazy because you make the decision only when you need to, as opposed to Eager decision making, when you make a decision when you think of the question.
Static typing is eager decision making. You have to decide everything up front when you don’t know enough information, and if you change it later, you’re screwed.
This is one of the reasons why the trend in computing is toward dynamically typed languages, and away from static typing. It allows you to make decisions later (at runtime), when you have more information. That allows you to be freer in your programming because you’re not making decisions based on guesswork. But most of all, it allows you to skip an entire step of development (laying out a class hierarchy) that will inevitably cause you pain in the long run when class A doesn’t inherit from class B, and neither implements interface C. This step becomes a much looser and more manageable hurdle when you can just make sure that the right methods are there, or better yet just mix in a module you already have.
The obvious next question is: what other decisions are we making too early? I wouldn’t be surprised if there are some huge ones out there. Paul Graham is fond of pointing out that the startups he funds often create a completely different product than they set out to create, and that seems like a pretty large decision to make lazily.