33.1 PROGRAMMING

---

Some concepts to observe,

- break a large program into smaller parts, and separate out operations as much as possible. Questions to ask are,

= do things need to happen at the same time?

= does a process occur all the time?

- develop lists of the data needed before starting

- find a way to keep programs compact, and more usable.

- plan on paper before starting

Write programs to have an executive subroutine

Use flags to pass messages between separated programs

put each separate program in a separate program file, and give it its own section of memory to avoid conflicts

If possible use subroutines to reduce redundancy

Build with testing in mind

write comments and documents as you go. It even helps to write documents before implementing - this gives more clarity, and exposes mistakes before they occur.

Typical problems in large projects include,

- amateur designers rush through design to start work early, but details they missed take much longer to fix when they are half way implemented.

- details are not planned out and the project becomes one huge complex task instead of groups of small simple tasks.

- designers write one huge program, instead of smaller programs. This makes proof reading much harder, and not very enjoyable

- programmers sit at the keyboard and debug by trial and error. If a programmer is testing a program and an error occurs, there are two possible scenarios. First, the programmer knows what the problem is, and can fix it immediately. Second, the programmer only has a vague idea, and often makes no progress doing trial-and-error debugging. If trial-and-error programming is going on the program is not understood, and it fixed through planning.

- small details are left to be completed later. These sometimes are left undone, and lead to failures in operation.

- the design is not frozen, and small refinements and add-ons take significant amounts of time, and often lead to major design changes.

- the designers use unprofessional approaches. They tend to follow poor designs, against the advice of their colleagues. This is often because the design is their `child'

- designers get a good dose of the `not invented here' syndrome. Basically, if we didn't develop it, it must not be any good.

- limited knowledge will cause problems. The saying goes "If the only tool you know how to use is a hammer every problem looks like a nail."

- biting off more than you can chew. some projects are overly ambitious. Avoid adding wild extras, and just meet the needs of the project. Sometimes an uncessary extra can take more time than the rest of the project.