Desk Checking
Ole Eichhorn has written a great essay on “the lost art of desk checking,” sharing how slow and painful experiences with debugging led to habits of deliberate and careful pre-planning and checking.
My own parallel experiences: Okay, I’m doing to date myself here too. I’m also 49 years old, but didn’t start programming until Senior High. First experiences were with Basic on a Xerox Sigma 7 (thanks, Xerox), and a Wang 2200B. Not much learned there.
I learned more during summer vacations, when I paid real money to the University of Rochester to use their mainframe. I discovered that my first APL programs actually worked. I tried my hand at IBM 360 assembly language programming, but debugging was expensive – each assemble/link/run cost over $2. So I started editing the binary object decks on a keypunch instead, reducing the cost of a link/run to something under 80 cents.
While I followed the technology curve and have all the modern development environment power tools, there’s nothing like designing cleanly and understanding what’s going on. To quote Eichhorn:
To write code I just look at my screen and start typing, and to fix code, I just look at my screen some more and type some more. So now, finally, I‘m done with desk checking, right?
Wrong.
I desk check everything. Thoroughly.
And this, to me, is a major league black art which is lost to all those who didn’t have to hand-punch cards and wait a week for their deck to run. It is a lost art, but an essential art, because all the tools which make entering code and editing code and compiling code and running code faster don’t make your code better.
