1. The first, most important and creative step is defining the external specification of the program. You cannot write the instructions for doing something until you know what it is you want done, so before you start writing a program, you need a clear picture of what it will do when it is finished. You have to imagine it running -- what does the screen look like? What actions can the user take? What happens when he or she takes each of those actions?
This step is analogous to an architect imagining then drawing pictures and plans for a house to be built. When the architect finishes, he or she turns the plans over to a building contractor who constructs the house. If the plans were complete and well written, the house will come out as the architect imagined it.
Similarly the external description of a program should give enough detail that a programmer could use it to write the program as you envisioned it.
You should prepare a written description, an external specification, of the program you are going to write before you begin writing it. For a short program, this description may be only one page long, but for a large program like Microsoft Word, it would be very long and detailed.
The external specification should show the appearance of the user interface -- which controls are on the screen and how they are laid out.
It should also specify the events that can occur -- the actions the user can take, and what the computer should be programmed to do for each of them. (As we will see later, all events are not caused by user action).
2. Build the user interface using the VS development system.
3. Code the event handlers. For each event you define in step 1, you must write an event handler, a subprogram telling the computer what to do when that event occurs.
4. When you first run your program, it will not work properly. Debugging is the process of finding and correcting your errors. In testing a program, you should give it extreme inputs in an attempt to force errors.
Some IT managers require programmers to write their debugging test plans before beginning to program. They assume that if the programmer does not have a clear enough external description to do so, they do not understand the problem well enough to program it.
5. The job is not finished when the program is working correctly. The programmer must prepare documents describing both the external specification and the internal design of the program. This documentation will be of value to users and programmers who must maintain and modify your program.
Many people may work as a team if a project is large. There might be architects, programmers, testers and documentation writers.
It may sound like you just work your way through these steps in order, but, in practice, you will find yourself going back at times. For example, while writing event handlers, you might decide you need to change the user interface, so you need to back up and change the external specification.
You might be tempted to skip some of these steps when working on simple programs like those in this class, but when working on a larger program, that would be a big mistake. The best way to save time on a programming project is to spend a lot of time on the external design. A well-designed program will be easy to code, debug and document. As they say "the best way to go fast is to go slow."