It's great you realize that planning will help you. The urge to dive into a project is frequently hard to resist, as anyone who enjoys programming knows. But the best ways to plan a project depend on a great many things. Some common factors that can affect your strategy:
in reply to Rewriting some code
- Architecture - language, platform, etc.
- Program size - programs with 500 lines and 500,000 require totally different approaches
- Timeframe - did you need the program yesterday, or do you have a year to get it right?
- Number of collaborators - it's much less hassle to do things yourself, but large projects require coworkers, and the red tape that comes with them
You need to know all these things before you start writing any code. Don't just think about them; write them down, or explain them to someone else. Structuring your thoughts in a more concrete manner will force you to really understand what you're doing. Getting the requirements right is the first thing you'll need to do. Next, look in more detail at what languages, algorithms, libraries, etc you can reuse. Compare a variety of them and see which fits your project best. Flowcharts and other graphical diagrams, as non-computer-esque as they seem, can frequently help you organize your ideas and find fundamental problems very early. The right design decision can save you enormous cost down the line.
Once you've got a good idea of how you want to structure your program, start looking at how to implement it in general terms without actually writing code. Most coders I know tend to itch to start writing code as soon as it's fairly obvious how to implement a routine, but restrain yourself until you know that the obvious way is the best way. My favorite tool for good program design is writing an initial draft in a sort of formal pseudocode called PDL (Program Design Language... see the book link below). Before ever writing a scrap of code, map out in detailed English (or whatever natural language you prefer) what your routines will do. This frees you from syntactical constraints of your target language and allows you to tell at a glance what routines do. Recursively revise your draft with increasing detail until you can go almost directly from that to code. Any logical flaws are much easier to correct if you uncover in the planning phase than once you've started coding. As an added bonus, once you fill in the code, you've got comments already there in the form of the PDL.
Your question relates mainly to the planning stage, but maintainability is also greatly influenced by how you write the code itself. Structuring routines and classes for maximum understandability and flexibility will always help you in the future.
One of the most valuable books on my shelf is Steve McConnell's Code Complete, because it address exactly these issues. I've had it for seven years and reread it every so often just to remind myself of how I should be doing things. Amazon has a list of related titles (which I can't vouch for personally, but look similar) that you might find useful.