Friday, September 17, 2021

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.

2 comments:

Doug said...

Great post, Alfred. You took me back to my early programming days of Fortran in Grade 11. Pedagogy, as we know it, was different then. Every program was worth 10 marks. We would code it and one of the teachers who commuted from London (an hours drive away) would take them home and drop them off at the University. Overnight, our programs would run and the teacher would pick them up the next morning. Our teacher would take the cards from the box and wrap them with the printout after checking it. If the program ran the first time, we'd get a 10. Errors? Fix and rerun for a 9, 8, ...

As I think about it, we mark crazy people poured over the code before submitting it to make sure that we got marks. It made us better programmers in that aspect. On the other hand, it deterred us from "trying stuff" or throwing in bells and whistles because the more sophisticated you got, the great the chance for errors.

Upon reflection, I'm guessing that it probably made me a pretty conservative programmer.

Thanks for the post and the inspiration to reply.

computer short courses in lahore said...

very helpful post!
computer short courses in lahore
seo course in lahore
wordpress training in lahore
social media marketing training