Coding with incomplete specs

With the current project deadlines it is important to have coding techniques which work when the specifications are being developed after coding has started. So how do you do this. I use two techniques:

Delay decisions as long as possible

I group the work items of an increment into three types namely:

Items that are fully spec'ed with specs that will not change, items that have incompete specs and then items that are fully spec'ed that might change due to dependencies on other incompletely spec'ed items.
First I tackle the completely spec'ed items that will not change and in parallel firm up the specs of the incomplete items that have dependencies.
Next I tackle the items that are completely spec'ed by still have dependencies on incomplete spec'ed items. Choose the order of these items and make a firm best guess decision using all the information that you have at this point on what the dependent item spec would be. After these items are developed the and the best guesss decisions are make ther might be some changes required later where you guessed incorrectly, but the decisions you have made will help define the outstanding specs.

Note that this is not procrastinating, it is a process of waiting as long as possible before you make the decision so that you can make the decision with as many facts as possible. Make a firm decision based on all the facts you have at that time.

Isolating unknown areas of code

The second technique I use is to isolate and code where the specs are unclear. Typically I would create an interface to the unspec'ed area or create a stub of some sort. This allows me to continue with the development without worrying about the details of the unspec'ed or unclear portion of code. When these spec's become clear I can then flesh out the stub or implement the classes according to the spec without impacting the other code.