Program Development Methodology or How to Write a Computer Program from Scratch

1. First make sure you know how to solve the problem by hand. Writing a computer program is essentially giving the computer instructions on how to solve a problem. But you can't give someone else instructions on how to do something until you know how to do it yourself. So start by working out a few problems by hand, to make sure you know what steps are involved in the solution and what landmines to watch out for ( like dividing by zero. ) This step will also provide you with some nice test cases to which you know the answer, for testing your program later.
2. Start with the boilerplate framework that you know goes into every program. For example, every C program you write ( as a new programmer ) will have the following structure:

		/* ProgramFileName.c

			This program does this and that and something else.

			Written on date by author for purpose

			Other comments as appropriate

		 */

		#include <stdlib.h> // Needed for the standard library routines
		#include <stdio.h>  // Needed for the standard I/O routines

		int main( void ) {

			// Declare variables to be used.

			// Explain program to user.

			// Get user input. ( And check if possible. )

			// Perform necessary calculations.

			// Echo back the user input and report results.

			system( "pause" );		// Only needed for some environments, e.g. DevC++

			return 0;

		} // main

3. List all the variables ( you can think of ) that you will need in your program, and list them right after the int main( void ) line. I like to list my data types in increasing size and complexity, i.e. bools first, then chars, then ints, then floats, then doubles, etc. Leave plenty of room to add additional variables later as you think of them. ( When writing a large program by hand on paper I usually reserve the entire first sheet just for listing variables, and start my code on the next page. ) As you write your program, this variable list can serve as a checklist to make sure you have accounted for everything.
4. Then start outlining the steps needed to solve the problem. If you have worked out a few problems by hand, then you should know what steps need to be done in what order. One good approach here is to go through and fill out a series of comments listing the steps to be performed, and then go back and put in the computer code corresponding to each comment. Many programs have a basic structure of (1) Read in problem input data, (2) perform necessary calculations, and (3) report results.
5. If a program is large or complex, do not attempt to write the entire thing in one pass. Write part of the code and verify that part is working, and then write some more. For example you might get the input data entry part tested and working before you write any of the code to perform calculations.
6. Evolutionary Development: If a program has special features, don't try to write them all at once either. First write a basic program that can handle simple cases, and then when that is working, add additional functionality, bells, and whistles.
7. If there is a particularly tricky or special piece of code, you may want to test it out first in a smaller test program. Write a small little program that contains only the special code, ( and any supporting code that is necessary to test it. ) You can use this to play around with it and try different things, and when you've got it working right you can then cut-and-paste the code back into your main program.
8. Program Testing: Have the program run some test cases for which you know the answer, such as the problems that you have already worked out by hand. Don't forget to test extreme cases ( huge numbers, tiny numbers, zeros, negative numbers, etc. ) as well as simple easy cases. Think about the results your program is giving you and ask if they are correct, ( or at least reasonable, if you don't know the correct answer. )
9. Debugging: If the program runs but gives bad results, there is probably a logic problem somewhere, although there could be other types of errors. The following techniques are often useful:

A. Print out intermediary values, so that you can trace the program's operation.
B. Comment out code that seems to be troublesome, to try and narrow down the problem.
C. Test tricky code with simple cases or in a separate simple program ( see #7 above. )