Documentation should be complete and signed off before the first bit of code is written.

If it's done that way, the code will match the documentation and the end-user will be happy. If it's done in the usual way, i.e. requirements are ignored, code is written before requirements are established, code is changed at random without any written documentation of the changes, etc ... then you end up with the "usual" mess that software produces.

Every code module should be directly traceable to a system requirement. If there's anything included in the code set that is not justified by some specific requirement, it should be removed. Deliverable software (and harddware) should never include provisions for future expansion that are not specifically required.

If tech writers are required to "read the code" then there should be ample comments at each line. Ordinarily, tech writers are dismissed before the code is written. This is to avoid the notion that the needs of the coder can be accommodated by the document. The complete document must precede the assignment of the coder!

If it's done in any other way, the end result will be a mess! Requirements will be unmet, budget will be "busted", and schedule will be "in the toilet." The coder should be told, "Don't make it "kewl", make it do what the doc's say."

RE