I learned just how powerful a technique the copying of large blocks of source code can be thirty years ago, when I was a systems engineer at IBM. My colleague, Garry Reinhardthe most talented programmer I have ever seen in actionwas working with me to develop the first online software package ever created for the apparel industry (IBM would eventually name it the Apparel Business System).
We were running a marathon for months. Not only did our programming work last into the evening hours seven days a week, but we were forced to do keypunching too. (Our team secretary didnt know how.) So, after we had done the coding, we had to keypunch our programs into IBM punched cards and run them through a card reader on the IBM System/370 mainframe.
This was laborious, because there were no online terminals; we had to key the entire source program for, say, customer master file maintenance into 80-column punch cards, then compile and test it. This we did at night at the IBM data center after the IBM customers went home to dinner.
Because we had no online source statement editor (to catch keypunching errors or programming syntax), undetected errors, as well as the slow mainframe compile times of the early seventies, made even relatively simple programs take a long time to complete. We had to wait until the next night to correct the simplest error.
Garry quickly discovered that all of the master files we used in our software package, such as the customer master, the style (or product) master, and the employee master, used almost exactly the same programming techniques for as much as 90 percent of the programs. So did files with header and detail records, such as the customer order file, the accounts receivable file, and the work-in-process file. Nearly the only changes needed in the programs were the file names and the fields used in each application, and some validation editing of the fields.
Garry produced an incredible amount of completed and working programs in a very short time by reproducing the completed Assembler source program deck (copying the source program) and making the minor changes needed for the next master file maintenance. This method sounds simplethe obvious thing to dobut back then, few programmers worked that way. Garry had to find a very productive way to work so that we could make our product delivery schedule with a quality product, and he had to do all the work himself.
The technique Garry came up with to dramatically raise his productivity thirty years ago is just as available to smart programmers today: Indeed, copying is the basis of many of the software tools that claim to multiply programmer productivity. The task is surprisingly simple: Find what is wasting much of your time and frustrating you, then look in your company library for already-invented code that takes care of the problem.