Not used properly, templates can do more harm than good.

There are at least two things that typically go into a template: Look and content structure. The look is the visual style like the fonts, the front page design, top and bottom texts and these sorts of things. This is what you should use your templates for. This is very useful. It makes all documents have the same familiar look. You can also include a table where you can type the author's name and the creation date, and a table for version history. These are things that won't interfere with writing the content of the document.

The second thing that is typically put into a template is content structure. By this I mean the predefined set of information that the document is meant to contain, and how to structure it. Like the long list of detailed section headlines, the description of each headline and the pre-written texts that is there to help writers so they don't have to write it themselves.

This content structure is the part I consider can do more harm than good. It is meant to help writers make consistent documentation that is sure to include all the parts that should be in there. But it is actually discouraging developers from thinking. Thinking about how to communicate by the document. It is reducing the process of writing into a fill-in-the-blanks excercise where the writer won't need to think outside of the helpful description for the particular section he is about to fill in.

By intention and not only by letter

So why is that a bad thing? Well, a technical document should help the reader to understand your thought process and your conclusions, the problem you are solving, how it will be solved, and why it was solved that way. Only with this information can another person really understand the technical decisions that the document describes, and implement the specification by intention and not only by letter. This kind of communication is impossible if the author of the document was simply filling in some text for all of the sections, and jammed in his class diagram. Of course documents written by templates aren't totally useless. Far from it. But they could be so much more useful if they where written in another way.

I realize that not using a strict template will put some more responsibility on the writer, but in my mind that is a good thing. They have to think about how they communicate. And if the writer is the same person that will be the lead of the implementation he already has that responsibility - to communicate well with his group. If they can't handle it, they need to learn how to write good documents, not how to fill in the blanks in a strict template.

But why can't people communicate just as well using strict templates?

Have you ever tried to use a template, but is wasn't exactly fit for your task? Say that most of the time you are writing technical specs for components of your system. So the template contains the obvious headings like Interface description, and Dependencies. Now, you want to write a technical spec for a windows service that you need in your project. It is sort of a component in the system, you think, and you have to follow the template anyway. But it turns out it doesn't really make sense. Under Interface description you write something like "The interface is the Windows Services Manager where you can start and stop the service". Ok, so what else is special about your Windows Service? Wouldn't it be better to just chuck the whole template that makes you write nonsense information under strange headlines, and just write a document that explains to your reader what the service is there for and how it's built?

Lets rather try and accomplish what the template was meant to do in the first place - help the writer to include all the relevant information, and keep the structure similar enough accross documents so that it's easy to find what you need in a document. The best way to do this is to have a separate document where you give some advice on how to write good documents. You can state things like that it's good to have an Abstract as the first chapter since this will let the reader quickly know what the document contains, and he can skip reading it if he was looking for something else. And that it's good to start by explaining what the problem is and how it is solved before you go into details of how it is to be implemented. Now the writers have something to refer to if they think they are forgetting something, and still they go through the thought process of writing that results in good documents.