<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?

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.

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.

</rant>

Comments welcome :)