@Ex094: It depends on the scale of the project, smaller projects require less planning, but the bigger the project is the better you want to plan it before actually even writing code, otherwise it'll easily turn into disorganized mess. With proper planning the actual coding will fly like on butter :-)
There are generally several phases to developing something, but it also depends on what the idea is, how large and such:
Planning & Program Description
First thing you could do is write down in advance what will the software do, what functions and features it will have, how will its user interface work and so on. Try to even think of possible functions you might want to add in the future if you want to keep expanding it, but you should have a good idea about what the software will do before you get to the next phase.
If you start coding immediately, you might think of new features and changes to the design on the fly, but your already written code won't be adjusted to deal with that, so you'll start adjusting it with various hacks to accommodate the new functions and over the time, it gets really messy and ends up being some kind of "frankenstein".
Architectural formal design / Organization
In second phase, when you have the idea of what will the software exactly do, you should make a formal design - divide the software into smaller, self contained components. If you were to write a image processing software, you might for example separate the code that modifies the bitmap data when you draw in the program, from piece of code that renders and receives input from the UI and another part that performs various operations, such as effects or loads plugins.
This way, more people can later easily work on the different parts of program and even if you work by yourself, it helps with organization - in certain part of code you are dealing only with specific task, not everything at once and then you connect these parts together (you also need to plan how will they communicate). Furthermore it allows a good portability (taking certain module and using it in different program) and expandability (it's easy to add new functionality to a module while keeping things consistent or add more modules).
Coding
Once the design is done, you'll start actual coding and implementing of the individual parts. During this part of the process it's a good idea to test the individual components separately, to see if they work right by themselves. If you don't test them before putting it all together, it will be more difficult to trace where bugs originate from.
Debugging
After you implement and connect considerable part of the code, you start with testing and debugging (although like I said, it's good idea to keep doing that from early on and catch the bugs early at the source) to remove any major problems you might find, so the program is usable.
Support
Once the program runs reliably, you can start distributing it for others :-) Of course usually you have to (or should) support it and help people solve any more bugs they find or perhaps implement new features and continue working on it. If you're a company, you probably have to set-up some kind of helpline to help people solve issues or even train them with the program and prepare some training resources.
Other stuff...
That being sad, these phases don't usually have solid walls between them, they rather "blend" into each other and you can often jump back to the architectural design phase to change something, when you discover a problem or need to change something.
Turning your idea into a program is balance between planning, flexibility, expanding, time of development and design elegance/clean-ness. Sometimes when things get too entangled, you might find it even easier to delete a chunk of code and rewrite it from scratch with the latest plan.
There are also some other important side phases: Documentation, that is documenting both the code and features and functionality of the program and marketing, which is spreading your work to other people (because if nobody knows about it, nobody will use it, no matter how good it is).
Personal example
I would like to stress the importance of the planning and architectural design phases, especially for larger projects. If you skip them or don't devote much time to them, your project will crumble easily, into a big pile of mess.
When I was developing my processor architecture for example, it was quite huge project and I was working on it alone. If I haven't split it into various functional units (which in turn had subunits) and didn't have proper planning (which surprisingly makes the coding and debugging part much shorter) I wouldn't be able to manage it and develop in such short time.
I hope this helps, let me know if you have any further questions :-)
]
