How to write a computer program

A new acquaintance from Hong Kong asked an interesting question: "How do you write a computer program?" Here is my email reply: 

My first reaction was to simply Google the question: how to write a program. Nothing worthwhile came to the top of the list, which surprised me. Let me try to answer the question... 

First of all, I am not a very good programmer. Although I was taught the basics of programming in a short course while at IBM in the mid-sixties, and although I worked as a programmer in the Fortran IV language for a year in 68, and directed the work of COBOL and RPG II programmers for several years thereafter, and wrote the initial several years of the development of TeleMagic in the Dbase II, III, IV languages, and programmed other projects (PAL, etc), I really am humbled by those programmers who have much greater talent than I do. 

Some great bulk of the programming I have done was with the excuse that I could not afford to hire someone else to do the work, or sometimes because I could not communicate to other programmers what I needed without actually programming it myself. 

 It is not my preferred activity, although it is immensely gratifying when the program finally works properly. I much prefer to do the design and leave the coding to programmers. All that being said, here's my typical approach, the way I learned it, the hard way, without any real training on the process: (it is very similar to the Think*Plan*Do*Repeat process)  

1. Imagine (with the help of the users) the Outputs. What is the result you want to achieve. What does it look like. 

2. Imagine (with the help of the users) the Inputs. In order to get the Outputs above, what Inputs to the system are needed? 

3. Imagine (with the help of the users) the Process. What must be done to the Inputs to create the Outputs? 

4. Document all of the above, using ordinary English. This is really the "meta-language" from which the actual code is created. 

5. Get approval of the users of the document (the customer, the user who enters the Inputs, the user who gets the Outputs). 

6. Make changes suggested by the users and loop back to step 1 until there are no more changes. 

7. Give the whole mess over to the programmers, who will make it work on a computer. 

8. Get user approval of the finished product. 

9. Loop back to step 1 with the changes. Proceed with next step after approval. 

10. Begin a period of trial runs with limited data. 

11. Loop back to step 1 after learning how the system doesn't work the way it should. 

12. Begin a period of trial runs with production data. 

13. Loop back to step 1 with the changes.

14. Go live and hope for the best. It is often said that the worst flaws of a program are not discovered until about 6 months after going Live. So it is then back to step 1. 

It is often said that software is ALWAYS late, and over budget.

Additionally, the worst bugs are usually discovered at least 6 months after the program goes live.