Archive: April 1, 2008

<<< March 31, 2008


April 3, 2008 >>>

the lost art of desk checking

Tuesday,  04/01/08  11:08 PM

<rant soapbox=”true” optional=”yes” >

Okay, I’m going to date myself here.  I’m 49 years old, and I started programming in Junior High, when I was 13, so my story begins 36 years ago.  The dawn of time, metaphorically speaking.

Back then, I didn’t have to walk to school barefoot in the snow, uphill both ways, but I did have to learn programming by submitting batch decks of cards.  Yes indeed.  My school had a deal with Northridge University whereby students could mail a deck in, they would run it, and then mail back the results.  I’m talking about snail mail, postman knocks twice and delivers once a day kind of mail.  Oh, and of course I didn’t have a card punch, so I hand bubbled the cards.  Yes, I do still remember Hollerith codes, thanks for asking.

Okay, so there I was, writing FORTRAN programs by hand-punching cards, and then waiting a week while the deck was mailed to Northridge, and I’d get the deck back with a pile of greenbar.  Now in this environment, a typo was expensive.  We’re talking a week wasted expensive.  Furthermore trivial bugs were not inconvenient, they were infuriating.  There was a big payoff in being careful.  Every program was laboriously written out (graph paper, baby) and then carefully desk checked, and then hand-punched, and then run.  Which could bring me to my point but it won’t yet.

Later I advanced to driving over to Northridge and using their card punch machines, but it still took hours to run a deck before you got your pile of greenbar, and it was still well worth carefully desk checking before submitting.  Aside from the lost time, resubmitting the same deck over and over was embarrassing.

Later I advanced to using a PDP 8, with a 110 baud teletype.  (If you want to know why I type so “hard”, it’s because I learned to type on a TTY where the keys had an inch of travel and required about 10lbs of force.)  I used a line editor and the TTY spit out hardcopy on greenbar.  Any kind of problem and you were wasting serious amounts of paper and time, so it was definitely worth desk checking before typing in a program.

Later I advanced to storing my programs on paper tape.  Yes, I do remember Baudot codes, thanks for asking.  You didn’t really want a typo in a paper tape, because editing was a bit lame.  You copied the tape to another tape up to the spot of the change, made the change, and then copied the rest of the tape.  Really.  Any bugs were not only annoying, they wasted frightful amounts of time, not to mention tape.  So yeah, desk checking was definitely the thing to do.

Later I advanced to using a “glass TTY”, a green and black 24x80 CRT.  Man, what an advance!  I could actually edit programs interactively – a line at a time – without cards, printouts, or paper tape.  Still, it took time to enter programs, and more time to fix them, and it wasn’t like there were debuggers or anything; this was the original “printf” debugging environment.  So it was still very beneficial to desk check code before running it.  As in, print it out, read it, look at it, analyze it, convince yourself it was really going to work, and then type it in.

Later I advanced to using full screen text editors – in fact, I wrote my own at first – and man was that nice.  You could actually read the program on screen instead of working from a printout.  Of course, you could only see 24 lines at a time, so it definitely encouraged tight code and small modules.  (Want to know why I put comments at the end of lines instead of on separate lines – now you know :)  And it was still a bit tricky to fix stuff, and still hard to debug – lots of paper later, you finally found the error on line 781, or line 78,100 - and so desk checking was still the thing to do.

Okay, okay, you get it, I’m a dinosaur, I’ll get to the point.

So today I have a huge LCD monitor with an amazing visual interactive tool like Visual Studio where I can have hundreds of modules all up at the same time in a color-coded full-screen interactive environment.  I can compile in seconds to find typos, and debug interactively to find logic errors.  I never ever print anything out anymore.  (In fact when I do have paper, I scan it in.)  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?


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.

Desk checking means carefully reviewing everything you’ve coded, running the code in your head before you run the code on your computer.  It means pretending you’re the compiler, and pretending you’re the CPU.  It means thinking about what is really going to happen, what are the boundary conditions, what are the possible error conditions.  What are the real world data going to look like.  It means you spend an extra five minutes or five hours so you don’t have bugs later.  And it is really important.

You cannot possibly find all the problems in a program just by running it.  For one thing, there are problems where the code is wrong, but it still produces the correct output.  There are problems where the code is unmaintainable, or incorrectly factored, or encapsulation is violated.  There are problems were there is dead code that is never executed.  There are problems where the style of the code is wrong, even if the code itself is right.  (Gack!)  There are problems where there are error conditions which are impossible to simulate so you can’t test the code.  Even if you step through the code one line at a time, carefully, you won’t take all the possible paths through the code.

Back in the day, desk checking saved a lot of time.  Weeks even.  And guess what?  It still saves a lot of time.  Weeks even.

The best way to write clean code is to relax, load up the code, full-screen, turn off all distractions (crank some Zeppelin), and just read through the code, one line at a time, one function at a time.  You’ll probably find a lot of little things which can be polished, adjusted, fixed, improved.  Most of them might not even be visible to a user, but the code is better for it.  If you spend a day writing some code, spend an hour desk checking it.  And when you finally do run the code, you won’t just hope it works, you’ll know it works.

Yep, even 36 years later, desk checking is well worth doing.


Comments welcome :)


Tuesday,  04/01/08  11:43 PM

Welcome to the April Fool's edition of Critical Section.  And no we don't suffer fools gladly or even at all if we can help it; you won't find anything foolish here.  In fact, let's see what's really happening, shall we?

Is Robert Mugabe negotiating to leave power in Zimbabwe?  Dare we hope?  We dare. 

Powerline skewers House Democrats' Incoherence.  "Today House Democrats appealed to ignorance, in their usual fashion, by summoning executives from the five biggest oil companies to berate them for high gasoline prices. This is fundamentally stupid in at least two respects...  First, these same Democrats purport to be worried about 'global warming' and committed to taking strong measures to combat it...  Second, if you really want the price of gasoline to fall, there is only one way to achieve that goal: increase supply."  One wonders if they just don't get it, or just hope that we don't... 

Jason Kottke notes "a surprisingly effective idea": using the Google Maps interface for reading a magazine.  I have to admit, this is really compelling.  (I sure wish Winding Road used this!)  Now that I've seen it once, I'm sure I'm going to see it again, and again, and again... 

This is pretty awesome: Dan Proops' oil painting of a dialog box, entitled "painting downloading, please wait".  [ via Boing Boing ]  René Magritte would have loved it! 

Some excellent news from Ottmar Liebert: his new album is almost done.  That it, almost done as in released, it is truly done as in recorded.  I cannot wait. 

Congratulations to Dave Winer on 11 years of Scripting News!  Not only blogging pretty much continuously the whole time, but great blogging.  We don't always agree but I always find what he has to say interesting and relevant, which I can't say about very many others.  Best wishes for the next 11 and beyond! 


Return to the archive.