One of the most important project practices is Communication.

At first, this might seem like a case of belaboring the obvious — sort of like stating that breathing is a best practice for living a long and healthy life. I mean, between meetings, e-mail, web sites, wikis, PowerPoint presentations and Word documents, it sometimes seems like we are constantly swimming in a veritable sea of communication, and the last thing we need is to be reminded to communicate.

Every once in a while, an idea crosses my path at the right time and gets fixed in my brain as part of my general Thinking Toolkit.

I experienced one of these events a few years back during a leadership class I was attending. The course contained a module on Polarity Management, and this struck me as such an eminently useful concept that it has stayed with me ever since. The basic concepts came from the book Polarity Management by Barry Johnson.

So how do developers know whether they are doing too little or too much documentation?

The first step on the road to documentation sanity is to ask ourselves whether we have a good reason for creating a document.

I remember being hired a few years back to develop a new system for my employer.

On my very first day, I was handed a couple of thick manuals that spelled out, in great detail, the development methodology that the company was using. As with any such approach, it described the various phases of our systems development lifecycle, and the primary documents to be delivered by each phase, with each successive set gradually moving closer to the level of the actual code to be produced.

Being the new guy on the block, I did what I was told, and followed the set of manuals pretty closely. By the time I was done with the project, I had my own set of binders, full of all the requisite documentation for the new system.