2.1. The Programming Process

Specification

A detailed description of what the program will do and how it will be used. The interfaces (how the program receives its data and how it reports the results) should always be included. Even for small programs, it is valuable to prepare a reasonably thorough specification because it encourages consideration of alternatives and records the choices made. For small projects, this can be just few rough notes. For large projects, the specification phase can fully occupy several people for several months and the output of the specification can be a large formal document. Non-programmers such as potential users, a marketing department and managers are often very active in the specification phase.

  1. Design

    A statement of how the program will be implemented. Again, the effort ranges from a few minute exercises to a large effort. Software design tools are often used in this phase. Things to consider:

    1. General flow of program.
    2. Data types and structures (objects) which will be needed.
    3. Algorithms used by the program.
    4. Procedures or functions which will be needed.
  2. Coding -- Implementation

    This is the part of the project typically thought of as the programming part.

    Humor – Kernighan’s Law

    “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

    It is normal to work in a tight loop as follows with an occasional re-visit of the design phase. [1]

    ../_images/develop_cycle.png
  3. Testing

    Debugging and testing are often confused. Debugging is what you do when you know that a program is broken. Testing is a determined, systematic attempt to break a program that you think is working. For large projects, whole departments will be devoted to testing.

  4. Repeat steps 1-4 as needed.

[1]More discussion related to the use of tools for doing each phase will follow.