Debugging–Slow is Smooth and Smooth is Fast

Mike Zamansky had an interesting post called  What They Used To Know that got me thinking about the old days. Now Mike is a youngster and didn’t really start in computers until the 1980s.  I started in the 1970s with punch cards and batch processing. That meant that there was no instant gratification seeing your program run.

With batch, one handed their cards to an operator and some time later, hours or maybe a day, one got their cards back with a listing that showed the results. Results usually meaning a list of errors that kept the program from running.

Desk checking, studying the listing and trying to fix as many errors as possible before trying again was a bit of an art form. To this day I will often print out a program to look at the big picture in a way that still doesn’t feel effective on a screen. It’s tempting to see that as a way to go – limited opportunities to have the computer check ones code.

There are downsides to this sort of thing though. Specifically, having limited runs or at least long waits between runs encourages writing large amounts of code at a time and discourages writing and testing small pieces of code regularly.

Being able to hit “compile” every other minute though tends to encourage, or at least support, the beginner tendency to “throw some code in and see what happens.” This wastes time in the long run and often leads to ugly, hard to maintain, and inefficient code.

The military has a saying that “slow is smooth and smooth is fast” that some what applies. Slowing down to really analyze code, think smoothly, generally leads to a faster result. Tossing code in on a wing and a prayer is not smooth but chaotic. Slowing down to really look at what is happening is smooth and looks slow to the casual viewer but leads to faster results.

As I was thinking tonight and asking, “what if we limited people to some limited number of compiles a day?” It seemed like a good idea until I thought of the possible problems. That’s when I realized that external controls on speed are not the answer. Rather the answer is for developers to regulate themselves. To slow down and focus in ordered to make faster progress.