This, most of all. Substitute native language if not English; the important thing is that the project be defined and developed in both a human language and a computer language, so that mismatches can be identified and resolved.
* Start by describing what you are trying to do.
* Specifically.
* Not 'build a web business to enable users to achieve their
potential', not 'create another library for X but simpler'
but *specifically what the software will do* and, most
importantly, the priorities of scope increase (it'll happen
anyway; just get the priorities and their order down in
text ASAP).
* Put it in a readme.txt or something.
* For any given subsystem of the code (meaning: any section
which can sort-of stand on its own) write another such file,
in more detail.
* Let these files guide your tests too.
* Keep them up to date. If priorities change, *start* by
updating the readmes. The code isn't immutable; nor is the
plan. But the plan comes first.
* When unsure how a new subsystem or feature is going to work,
write out your ideas and thought processes in text. Don't
start coding at all for a day or two after you sketch out the
basics. *Append* to this file instead of replacing large
parts.
[edit] Wasn't intended to quote that part (sorry to mobile users) but I can never remember how to get bulleted lists on this site...
I found that combining such approach with writing down basic interfaces works really well - after i have a rough written idea i iterate over interface design with full descriptive comments of both the interface, and the methods.
