Every once in, unfortunately, a great while, I find it useful to “go back to basics”. By this I mean going over old textbooks just to see if there’s anything there that might help me in the development process. I did this just recently, and stumbled upon the following sentence, “The worst time to write documentation is when the project is completed.”

This is exactly what I had been doing. Further, for my entire career (nearly 20 years) specifications were something I scribbled on a legal pad and later threw away. That sentence above got me to thinking about how I approached the development process and reminded me of an old programming axiom, “The sooner you start coding, the longer it’s going to take.” Now all jokes aside (such as, “Well that means if I don’t start, I’ll be done yesterday.”), it really has the practical implication of, “The better you plan, the faster you’ll finish”.

As a result of the above, I started writing formal (but rather general) specifications as the project has evolved, I’ve updated the specs, as well as documented (technically) the programs, forms, objects, etc., that I’ve created. My general impression is that once I’m finished, writing the user documentation should be a snap because I know from the technical documentation exactly how things do work, as opposed to how I think they work.

The purpose of this post isn’t to elicit a response per se, but rather spark discussion on this topic. In short, how do you feel about what I’ve just written? How do you approach this?

As Mike Myers on Saturday Night Live used to say in his “Coffee Talk” skit, “Talk amongst yourselves.”:-)