[Egg 3141592654]

I personally need a lot of paper when designing code, especially robotics code. The order I think in goes as listed:
1. Get the goal, what is the final product expected? What is the hardware and how will it be used?
2. Write (yes write) pseudo, you will be shocked how many errors I find when I write out a rough map of what im doing. In this rough map, I dedicate a page to describe variables and methods with a little reason as to WHY I need it. I can't expect myself to come back to work after a break and have the same mindset as when I left, so I need a refresher.
3. Collect data. Chances are, the task has a little hole where I say "I need a tad more info here." Like in the case of calibrating a PID with pots, or maybe my knowledge about a structure or rebuilt method isn't 100%. Naturally, I do static tests and research to plug these holes. Graphs, charts, you name it and I probably have used it to collect data and weigh options.
4. Fill the pseudo with real code, WRITTEN in whatever language im doing.
5. Break my code into small test bites and hand check each bite before testing the whole. I determine bites by ordering the final code's functions from really basic and easy to test with less risk to very risky and hard to test. As an example in robotics, communication first, then drive, etc.
6. Type the code in order from previous step and test after each addition. During these tests, I write down what happened, in case I forget or whatever.
7. When the code is all done, release code as first version and implement into final product. Repeat for patching.

Personally, this all breaks down when I use labview because it is difficult for me to put my code into the pictorial form. I know how and why things work, I have done java for 4 years and have recently been exploring the boundaries of c++, but even after 3 years of robotics, labview is still hyroglyphics!