Depends on development methodology the fast answer is "When you have enough information to begin writing code".
My thinking on what "enough" should be is something like ...
- I wont be rewriting large portions later.
- What i'm writing is a small enough chunk that i can handle it as a "task".
I see so many people taking on tasks like "build the terrain" ... that's such a wide scoped task that it could take weeks and you have no idea of weather you are wasting your time or not.
I would go with smaller tasks like ...
- investigate potential options for terrain generation.
- implement a proof of concept.
- design the solution.
- Begin development on terrain component (basic form only).
- Add trees, buildings ect to terrain.
This works for me because I take an agile approach to my design, I pick up a small chunk of my project at a time and build it, then move on to the next.
Waterfall based development means you must have the full details of your project from start to finish before you begin.
My experience is that this is falling out of favour in all but the most elongated dev processes because of the time taken to plan such a project.
Typically waterfall based dev process involves just as pmuch planning time up front as the dev time that follows.
Simply put ...
Planning time - 1 year
Dev time - 1 year
Scrum / agile:
Planning time - 1 week
dev time - 2 weeks
You also have to factor in testing time and other process based time allocations (proof of concepts, meetings, design time, delays).
My advice (best i can give) ...
Build a plan for a unit of work, then build to that plan.
If the plan needs to change you should stop all development work and consider the impact of the change, update your plan then begin again.
Once the unit of work is developed ensure it gets thoroughly tested then repeat.
The agile approach (it works well for me).