Step 4: Write the Project Program as a Prototype Program

When you get to the third step in this process of summarizing and formatting and printing the report to the user s requirements, your print program may ultimately turn out to be 2,000 or 3,000 program source statements long when it is put into production.

What I almost always do when doing this kind of project is find an existing production request/extract/print set of programs for the same end user department and copy it to my development library, renaming the programs to those of my project. I then strip out the extraneous code from the other application and test the prototype (skeleton) program stream to see if it displays the requestor screen, accepts it, and passes control to the selection and print programs. I am happy if my first print output is the expected report headings.

Then I add in the specific program source code for this project, testing as each block of logic is added to the prototypes program streamand presto, the whole thing usually works very quickly.

Writing a prototype program is a very efficient way to attack a project. You write a few lines of code, get a clean compile (meaning that the program works in terms of the syntax of the language), and then you constantly build on that.

What you dont do is write a many-thousand-line program and then throw it into the computer. If you do that, youre likely to come up with hundreds (or thousands) of errors. Its far better to write short and build on success. You put down your fundamental logic, put a little bit into the computer, get a clean compile, and then test that skeleton program. As you go along, you add a few lines or thoughts, a little bit of logic. Its wonderful to be able to demonstrate , over and over, that youre correct.