4.3 The Write Tool

It seems that every time I get a new, better, computer, it is always harder to do the things I used to do so easily on my old, obsolete computer. On my old CP/M computer I had an 8080 assembly language program called Write that printed files on the printer. It put a title at the top of the page, a page number at the bottom, and never printed on the page perforations. It would double space the listing, too, if I asked it to. I was disappointed when I discovered I couldn't do the same thing on my "advanced technology" clone.

The DOS PRINT command prints files, but it just copies them straight to the printer, with no headers or page numbers, and doesn't even skip over page perforations. I bought a well-known word processor from a major software house, and thought I could use it to print flat ASCII files. I can, but it sure is a nuisance. The command sequence to print a single-spaced file is:

<ESC> TRANSFER LOAD FILE.EXT <CR> <ESC> FORMAT DIVISION PAGE-NUMBERS YES <CR> <ESC> FORMAT DIVISION MARGINS 0 <TAB> 0 <TAB> 0 <TAB> 0 <CR> <ESC> PRINT PRINTER <ESC> QUIT NO That doesn't put titles on the top of every page. (I know there must be a way to get titles, but I haven't figured out how yet.) If I want to double space it I have to do all of the above, plus <SHIFT> F10 <ESC> FORMAT PARAGRAPH <TAB> <TAB> <TAB> <TAB> 2 <CR> somewhere in the middle.

Oh! how I longed for the good old days when I could WRITE FILE.EXT. It didn't take too long for the frustration level to build to the point where I translated my Write program from 8080 assembly language to Ada. Figure 39 shows the first version of the Write program, and Listing 62 shows the final version.

4.3.1 Error Recovery and Help

Figure 39 was a direct translation from assembly to Ada. It didn't have any help features because I wrote the program for my own use and didn't need them. When I decided to publish it, I knew other users might press the question mark key to get help, so I had to include NEEDS_HELP handlers. I suppose I could have put one big help procedure at the end of the program that explained every option, but then the user would have to read all the answers and figure out which one answers his question. I prefer to give the user short, pertinent explanations that help solve the immediate crisis.

What managers and programmers often fail to realize, is that a major portion of a program with a user interface will be devoted to error recovery and help messages. Everyone expects a routine that asks the user for the first page number to include some statements that convert a string to an integer. They often don't realize there must also be some statements that know what to do when the user says the first page number is "banana". Look at how much of the Write program is devoted to error recovery! Compare Figure 39 to Listing 62 to see how short the program could be if I left all the error recovery routines out.

The final typesetting process may change the exact number of lines in these two versions of the Write program, but before reformatting them to make them fit on the printed page, the original version was 57 lines and final version was 145 lines. That means 57 of the lines in Write are doing the work, and 88 lines are just there for error recovery. That's a 154% increase in program size to make the program user friendly. The 154% figure isn't an absolute constant. The amount of expansion depends on the number of questions you ask the user, and how verbose each help message is, but it isn't unusual for programs with extensive user interfaces to more than double in size when error recovery and help messages are added. Take that into consideration when you are estimating the size of a software project, and don't be naive enough to think that error recovery will be 2% of the total software effort!

Contents | Next ...