I spent a substantial part of my engineering career programming, starting with geophysical-type cases when I was working my way through school. One or two stand out as the types of screw-ups this column recounts.
The first was back in the days of CDC 6000 machines, in the days of programming on cards, FORTRAN, in fact. In those long-gone days, the compiler output was commonly punched out as a deck of cards. A "job" was fed into the machine as a deck of cars followed by data also punched on cards. So, from the heft of the stack of cards, it was easy to get a visceral feel for the efficiency of the program.
A guy I knew needed a program to do some fairly simple data manipulation. After a few months and failure of the program to do what was needed, he told a friend about his troubles. The friend was able to write a program in a couple of hours that not only did what was needed, but was one-third the size of the original program.
Decades later, in the days of NextStep, I was asked to help solve a disconcerting "memory leak" problem in a large piece of special-purpose business-processing software. The leak rate was high, about a megabyte a minute, which wasn't tolerable in working software. I set the software up on my computer running the test suite and let it run for about 10 minutes. Then, I stopped the code, converted the Next swap file to a regular file, sent it though strings, piped it into a disk file, moved the file to the local server, and emailed the people who had asked to take a look. This listed all the occurrences of readable text and sorted it with a count on each identical string.
About 10 minutes later, several of the programming staff came by wailing that everything was leaking. They figured out that someone (who had by that time left the company) had turned on the "No reuse" flag in the compiler to help with debugging, so no memory was being returned after temporary use.
Keith Henson is electrical engineer, a proto-transhumanist, and a writer on life extension, cryonics, memetics, and evolutionary psychology.
Tell us your experience in solving a knotty engineering problem. Send stories to Lauren Muskett for Sherlock Ohms.