Data communications over telegraph circuits 1918

Morten Reistad

These are excellent points and many technical people don't understand them.

Every computer program should have appropriate (depending on criticality) failure exits, even for things that are never supposed to happen. Because they WILL happen.

Failure points should give out as much diagnostic information as practical so that recovery can be quick.

As part of system design, questions must be asked what will happen if a particular function fails. What are the consequences of failure? What are the backups (either another machine or manual procedure)? What are the recovery procedures? All the trade offs and costs must be weighed.

For example, suppose you take different actions depending on a code in a field. The code was supposedly edited elsewhere. None the less, you should have a drop through 'catch all' if the code doesn't match any known conditions with some sort of intelligent error message. Many programs in that case just abend.

Another example is data controls. Back in tabulating days, IBM and its customers were very big on these. There would be quanbreasty, dollar, and "hash" counts of every record in a file for both input and output with balancing instructions and the process wouldn't be considered done until it balanced. Non-accounting systems would have different controls, but should have some sort of independent check on that every input received by the program created an output and stuff isn't flying off into space. Controls must be more than you accepted 23,533 records and wrote out 23,533 records. You should break it down such as 20,000 type A records, and 3,530 type B records, and 3 unknown records.

Every time a data record is created it should have a time-date stamp. Every time it is updated it should have a time-date stamp and update-source.

I can't tell you how many times such controls--when they were there--helped me quickly diagnose and fix a problem.

It frightens me how so many people in the information systems industry are not aware of these basic principles. Part of it is because they date back to punch card days and seen as obsolete, but they are most definitely not. Part of it is because there is a cost to them of clerks to check the controls and dig out the problems. Part of it is that the technies--those who went through electronics or compsci training (rather than application training) don't think in these terms--to them, a backup is a second power supply. They don't spend enough time understanding the end customer.

Every systems developer should spend time in the front selling the shoes or cashing checks or whatever the business is so they understand first hand who the custoemrs are, their needs, and their expectations.