Seven Deadly Sins of Programming – #6

Way back in my early career, I worked on a graphics program written in FORTRAN that was used to plot engineering data.

It ran on Tektronix 4014 terminals.

Our application – known as E.G.G. (Engineering Graphics Generator, one of a whole series of not-very-creative punny names used by the group) – used a menu-based approach. The user would place the cursor (moved by the thumbwheels on the right) over a menu option, hit the spacebar, and then the code would figure out what to do.

The internal architecture of the app was really pretty good. There were, if I recall correctly, 39 different screens, and each item on the screen had an id associated with it. The code would find the right item on the page, come up with a numerical code (menu number * 100 + item number), find that in an array of function pointers, and then call the appropriate function.

It worked fine, and allowed us to have a batch mode as well.

But after I started playing around with it a bit, I noticed that the command dispatch was a bit slow. After you selected an item on a screen, it took at least a couple of seconds for the screen to erase and redraw (this was running on shared Vaxen, so you didn’t get much CPU time, and what you got was fairly slow).

I did some digging, and found that the original developer (no longer with the group) had written the item lookup code using a Fibonaccian search.  This is a search that is similar to binary search, but doesn’t require complex operations such as divide by two or shift right (that alone should tell you the vintage of this search).

Such a search *may* have made sense on earlier systems, but on Vaxes, both the divide by two or shift right are in the hardware. So, we were using a search method optimized for constraints that we didn’t have that nobody in the group understood, in an attempt to be faster than binary search.

But it was a *clever* algorithm.

At this time, we had about 1200 items in our dispatch table. The first thing I did was build sub-index that stored the starting index of the first item in each menu, which meant the search space for a typical menu item went from 1200 items to about 30 items. The second thing I did was switch to interpolation search, which, given the nearly perfect distribution of items numbers within a menu (most menus had item numbers from 1-n, with very few holes), gave an almost perfect search. And it was code that most people in the group could understand.

So, the dispatch time went from a few seconds to about half a second, and I wrote up a “cost savings” in which I multiplied the number of users we had by the amount of time they used the application by the number of menu picks per hour, and figured out that I had saved the company around $30K per year. For which I got a $100 gift certificate.

So, what’s the point of that story?

Well, it makes me look good, which is the primary goal. It also illustrates that cleverness is an over-rated attribute of developers. How many times have you seen:

for (int i = 0, j =bounds; i < upper; i++, j += JUMP_SIZE)
{
    …
}

That’s somebody who is trying to be clever. They should have written:

int j = bounds;
for (int i = 0; i < upper; i++)
{
    …
    j += JUMP_SIZE
}

Which takes us on a long and tortuous trip to

Sin #6 – Inappropriately clever code

What examples of this have you seen?

(these will be in reverse order…)

#7 – Excessive Coupling

We start out with a simple one.

Coupling is obviously a necessary evil. The Console class, for example, wouldn’t be able to send text through Win32 without being coupled to Win32.

Given that, less coupling is nearly always better that more coupling. A few cases that I see:

1. Using switch statements rather than polymorphism or interfaces.


2. Classes that do too much, rather than being focused on a single goal.

What do you think? Do you have more examples?

From a email:

One of the comments on my last post reminds me of a story.

Back when I took driver’s education  – which would have been the fall of 1979 – one of the modules of the class was spending time in the “simulator”.

I used quotes around term “simulator”, because what it really was was pretend driving. Less like playing a first-person driving game – not even like playing Pole Position – but more like playing with one of these:

But less interesting…

Here’s how it worked.

You sat in a room with about 12 other students. In front of you you had simulated controls – there was a speedometer, a steering wheel, turn signals, brake, and accelerator. At the front of the room there was a movie screen, on which you would watch a movie taken out the front of a car, and while watching, you would pretend to drive.

The sole feedback system consisted of a red light on your console. If the system – assuming it’s not to grandiose to call $2.00 of electronic components a system – thought that you were outside the acceptable parameters, it would light up the red light, and you would come to the attention to the drowsy shop teacher who had to get up at 4:30 to run this thing. I think it also logged your non-compliance, probably using cuneiform.

Each of the consoles had a speedometer, which ran off a motor which got its input from the accelerator and throttle. That helped everybody develop the all-important skill of keeping their fake speed correct.

Rudimentary motor control skills were enough to be compliant in most cases – presuming you could figure out what was coming up in the old, scratch movie. One day we were doing some freeway driving – which meant I was “traveling” at the highly patriotic double nickel – and we got into an interchange to go onto another freeway.

Or at least that’s what I thought it was. But it turned out that it was a right-turning exit that ended in a stoplight. By the time I realized that, I only had about a second before the car was coming to a stop. I spun the wheel, started braking, and as the car in the movie stopped, I looked down, and noticed that my speedometer was dropping through 40 MPH. It took at least another second before it dropped to zero.  I took a deep breath, and waited for the approach of Mr. Schmeer.

And the red light stayed off.

Turns out that the system didn’t check for your speed – only for your inputs. I was on the brakes as I came up to the light, and that was good enough for it. Similarly, if you were turning to the right, it didn’t differentiate how far you turned. You just needed to turn.

Simulator class was a lot more fun after that.

A while back, I made an offhand comment about something being one of the seven deadly sins of programmers (/programming/developers/software engineering/coding/…).

At the time, I really didn’t have 7 things in mind, but after a little thought, I came up with what I think is a good list.

But before I write the first entry, I’d like you to spend 5 minutes and write down your list of deadly programmer sins. Though 7 is the canonical number of sins, your list can have any number of items. After I’ve gone through my list, I’ll do another post where you can share your list.

[Update: Sorry I wasn’t clearer. Write your list down, and then post it when I’m finished. Or post it now on your own blog if you’d like]