Rule 2: If It's Not in the Spec, It Doesn't Get Made
It's easier to change words on paper than code in play. The specification is a living document that describes what the software will do and how it will do it. Change is inevitable as the software being developed becomes better defined. Going to code before a valid written specification of the software is in force is costly in terms of time, money, and brain power. The act of maintaining a specification (albeit a continually changing specification) creates a development discipline that adds to the overall quality of the software being made.
In my experience, once the heat is on to get the product out, maintaining the spec goes out the window. And as the specification goes, so goes the software. This is not to say that no coding should take place while the specification is being written. What I'm advocating is that no new code be added to software until language is added to the specification that describes the nature, functionality, and implementation design of the feature under consideration. The act of putting thinking into writing makes an idea clear to all. Having a common document for anyone and everyone to reference creates a shared understanding of the work at hand, prevents faulty implementation of a feature due to lack of clear understanding, and, in some cases, brings to light inconsistencies in and unanticipated costs of the feature itself.
I'm not the first person to proselytize the need for written specification before going to code. Other writers have done so before me. However, as I mentioned above, when the heat is on, the spec often goes out the window. The easiest way to make sure that the written specification is respected is to continually ask for a written description of the work that you are to do, before you do it. This is not an easy task. It takes courage to ask a client for a written specification when none is provided. And, as we all know, some days we're courageous and other days we're not so brave.