"I want to take what I put on paper and have it work in the program the first time with minimal changes."
I almost lost a mouthful of Pepsi right there.
"I would like to plan my next vacation so nothing goes wrong."
OK seriously, while all the previous quotes sound similar to me, there is some value to planning.
Accept that most of the time you spend planning is wasted when the basis of your plan is significantly changed.
I have been asked to get started on the program before the hardware is finalized several times. That was fun.
I read and re-read the spec multiple times and ask the designer for details and more information until I think I know exactly what is supposed to happen in each area of the machine. Week one sees very little if any code.
Then I think it over and organize a simple structure of the over-all project. I usually do this in my head, some people use EXCEL or a charting software to make a flow chart of the process. All this might help you think about the flow, but most of it will be wrong as you start programming. Again, do these steps with the realization that none of this is intended to be perfect, it is a general plan.
Then Define all the I/O, some people do this in EXCEL or WORD, I do it in the hardware config where I only do it once.
Then I go back to the spec.
I blow it up and pull it apart into sections on 11X17 and pin it to the wall.
I write some general flow control code and set up a skeleton frame work.
Then go through and define some datatables to hold data in a reasonable structure that works for each section.
Now study some specific issues in each section. Identify things that might be used in several sections. Think big and write small re-usable modules of code. I like making LEGO code. I could write something specific to each section, but with a few variables and some parameters, I can write a section once and re-use it.
Make yourself a library to stop the copy paste of code.
After I write the LEGO modules to solve some of the tricky parts, it gets easier to plug the modular blocks into the skeleton. I will spend a week on one function if I can re-use it more than twice. After two or three re-uses, the investment pays off big.
About this time the boss shows up with a new spec. You know you are on the right path when you just smile and re-arrange your blocks.
I have written ONE small example program that I wrote out in 20 minutes or so and it worked the first time with no edits.
I would not expect this to happen frequently with a program of any real complexity.
Over all a flow chart is a good visual aid. Add a lot of white space so notes can be added to it as you go.
The added benefit to something like a flow chart is that non programmers can look at it and follow along. And some people ask for a flow chart as part of the documentation. Then you can just clean it up and give them a copy of yours.
But while all the ideas on this thread are great advise, you have to find a system that suits your mental process and the tools you have on-hand.
You might want to spend a few minutes after each project to re-think your approach and give yourself some feedback on what worked and what didn't.
Anything that was difficult, should be smoothed out so it is easier next time.
)
