My trainer has me timing my morning workouts as one way to track my progress. One day I realized that I had rushed through my workout, paying more attention to beating my previous time than to my form. Needless to say, that workout wasn't very effective.

It wasn't until I was talking about it with my trainer that I realized that experience was just like many others I have had and have watched others have. What's the point of rushing to beat time if quality suffers as a result?

Back in the day when I was first learning Windows programming, I specifically hunted down books that explained how to use the wizards because all those nitty-gritty details the wizards glossed over would only slow me down. Until of course I needed to do something the wizards didn't handle (which seemed to never to take very long), at which point I was completely lost, mired in ropes of wizard-generated code I didn't understand.

I find that unit tests save me enormous amounts of time debugging my code and fixing regressions, even factoring in the cost of modifying the tests to keep pace with product changes. I'm not always good at explaining their benefits, however, and so I have seen people skipping unit testing in order to get their code into production faster, only to spend double or triple the time they "saved" debugging that code once it's in production. And I have seen people spewing out huge amounts of test cases which they then proceed to completely ignore, so that the number of test cases failing due to "test issues" (i.e., test case bugs) grows and grows and grows.

One afternoon I was talking with a colleague who was rewriting some code he had written at four in the morning. "That's why I don't write code at four in the morning", I said. "But I have to get my work done", he replied. "So you don't have time to do it right the first time but you have time to do it over?" I asked. "Yes."

I may as well have not done my workout that morning, for all the good it didn't do me. The wizards got me to a skeleton app quickly but slowed me down soon thereafter. The team that ignored unit test failures spent time debugging their test cases later, and the team that ignored their test case failures spent time fighting product bugs. My friend may as well have not written that code seeing as how he had to write it all a second time.

Slow and steady wins the race. Doing it right the first time helps. Keeping it right thereafter helps too. All this "slowness" actually helps you go faster. At least that's what I've found. How about you?


*** Want a fun job on a great team? I need a tester! Interested? Let's talk: Michael dot J dot Hunter at microsoft dot com. Great coding skills required.