Figure out what you intend to do, in all respects, before you attempt to write any code.

You're a man of the old school. Waterfall et al. maybe.

Been there and done that. And, for at least 2 in 5 of the projects I was involved in where this methodology was used: requirements were gathered; a design specification raised and reviewed; test plan drawn up; and an implementation plan put in place. Before the ink was dry, the project was cancelled because someone had beaten us to the market or customer.

Customers rarely know what they really want until they see it. Market places evolve faster now than ever before. Requirements change over time. But mostly, it is very rare, unless you are designing your 100 th XYZ, that anyone can sit down a write a specification based solely upon what they already know.

Whilst it is very rare that a radically new algorithm (for anything) is invented, small evolutions happen all the time. And once you start combining several general purpose algorithms, with domain specific knowledge, the scope for innovations grows exponentially. Predefining everything becomes a good way to stifle such innovations, and is a death knell in emerging markets and growth areas.

Flexibility is the key. And that requires starting projects with some level of unknowns, and living with them. Prototyping as you go. Active and willing incorporation of changes to requirements on the fly is no longer taboo, nor even a nice to have, but one of the requirements of most every new software project.

Whether it is the ability to send updates to remote rovers on Mars; adapt to the overwhelming demand for openness on the iPhone; or competing with the ever-evolving feature-itis of your competitors search engine or community web site. Passive, fixed in stone development cycles are a thing of the past. And on a personal note: Good riddance.