A really interesting entry this one from Coding Horror: Quantity Always Trumps Quality
On first read, I was really, really excited by the ideas presented there. It makes sense: you learn more about programming via the coding process and reviewing the outcome than you do *not* coding and just planning. Way back when I was a rhetoric & composition teacher, I used to teach a very iterative approach to writing: you're constantly going back and editing, rewriting, starting over with new ideas, splitting topics off, all sorts of things. You'd throw away ideas, come up with new ones, and keep working, getting better and better with each iteration. It made sense to my students, too: they really did seem to get better throughout the process, from the beginning of the semester to the end. Coding is very much like the writing process in that sense: the first iteration of a thing is very much likely not the thing you end up with. You'll fix bugs, refactor classes, and roll version numbers.
But then I started thinking, both examples (my teaching experience and the pottery class from the Coding Horror article) have one thing in common: they're both taking place in an educational environment. In both environments, there is very little consequence for short-term failure: you basically get to start over when you throw a piece away. As well, you get to "waste" resources: writing is just paper and pencil (or electrons and photons on a computer and screen) and pottery is clay, so you can basically make something and get rid of it if it doesn't work out.
This is in stark contrast to the workplace where time is the resource in shortest supply. Any time used that doesn't result in some deliverable is basically time wasted, and in the context of coding as a contractor, it's wasting the client's money. So I started thinking again about the writing process The first part of the process was *always* trying to figure out what you were trying to write about, even if eventually you threw that initial idea away. It wasn't necessarily coming up with a formal outline, and it may have even involved writing a few paragraphs and seeing where they led, but there was always some attempt to define where we were going before *really* starting off. (I'm guessing, too, that the pottery students also needed to at least have *some* idea about what kind of piece they were trying to make . . . they probably didn't just throw a blob of clay on and start turning.)
As well, there's another big difference between the educational environment and the workplace: in the workplace, people are assuming competence. The pottery class was training people who didn't have experience in how to create these pieces; it makes sense, then, that the more pieces you can create, the more experience you'll gain. Same in the writing class, where the more you write, the more you learn. It's different in the workplace, though. You're not there to learn, necessarily; you're there to produce quality products. You may learn along the way, you may have educational opportunities, but the primary reason for you being there is to make something worthwhile as efficiently as possible. And that means that you're in a position where you don't throw things away because they don't work: you spend some time planning so that they'll generally work on the first pass.
That's not to say that you won't refactor, revise, throw away prototypes, etc. But the idea is that you won't do that as often if you sit down to plan a little bit and draw on your own experience. So while the article sounds good at first blush, I think it may apply more to hobby projects we have to learn things about new languages or techniques than it does to our professional environments.