In computing’s early days, a programmer could walk inside a computer such as a UNIVAC, and physically remove the bugs which were causing an application failure. These were insects that had flown inside the machine and become lodged in the circuits. Most software bugs, then as now, are not caused by insects but by logic flaws.
For most applications, it is virtually impossible to foresee every problem which might arise during the systems development phase, and the picture is often complicated by internal pressures to meet delivery targets and stay within budget. With multiple users of the finished product the adage to use in programming is “if anything can go wrong it will go wrong.”
My own philosophy in testing has been to give the application to someone who knows the system generally but has not been involved with actual development. Their mandate is to throw everything conceivable at the application: wrong data, wrong control buttons, whatever takes their fancy. If it “bombs”, the application needs revision. Of course, there are some things that cannot be catered to. I have had two situations during my career where the site running the application has been struck by lightning, and sunspots today can affect applications using satellite transmissions.
The increasing diversity of today’s IT environment complicates the programmer’s life. Often, the application has to link with other applications and certainly, for now, with flawed operating systems. Each interface will have “bugs” of its own, and the application developer has little control of that situation. The application logic must cater to bugs within the operating environment.
Interfacing with other applications can be quite tricky. In many cases, the data to be sent or received will have a different structure, a situation further complicated when the linked application itself is in a development process. Linkages where the language used is Java may be subject to incompatibilities between the Java run systems used. This was particularly aggravating with early Java, and I am not sure it has improved much today.
Many applications for enterprises also have to interface with servers, networks and the Internet, adding further uncertainties to the life of the programmer. Response times for these may be critical. The SARIS search and rescue system data for a rescue came from multiple databases across Canada (weather, aircraft and ship movement, hospital and airport facilities and capabilities, satellite information etc.) and had to be processed immediately for the search to be successful. Other important but non-critical data had to be catered to by a later process. The system also catered to a network having more than one transmission speed between network nodes.
Another concern is when application documentation should be done. Some of the early applications with satellite data are still not documented and maintenance has been virtually impossible because nobody knew the software structure. Documenting too early means a constant update as the development proceeds. Documenting at the end of the development tends to be sloppily done because programmers want to get on with their next and likely more interesting assignment. In many cases, the developer is poor when it comes to written communications.
It is preferable to have a good technical writer who interfaces with the application development team as it progresses. The document produced must include what a user needs to know in order to use the application, but also must include sufficient technical background for the application to be maintained as circumstances change months, or even years, later. This documentation should also be of use when the system is replaced by a newer version, so that all items considered to be important can be included in any new version.
Perhaps the most interesting applications to develop are those where a prototype is developed at the frontier of IT. In this case, one is pioneering and developing extensions to IT, making the testing and documentation of crucial importance when the prototype leads to a useful and operational system.
In all cases, remember that application maintenance is one of the most important areas of IT, although it can be boring. Arrange your application code and documentation in such a manner that maintenance is as straightforward as possible.
QuickLink 054114
— Hodson is a theoretical physicist, speaker and writer. He can be reached at bernie@genetix.ca.
