I am a big fan of using stores to teach. Stories are more memorable that contextless theoretical statements. In my career, over fifty years of programming, I have run into a few that I have told again and again. I thought I might share a couple of short stories here. I'll start with a story about why hard coding numbers can be a very bad idea.
Some years ago I was working on a team of five people creating a huge test structure to test computer systems. The systems were called VAX Clusters. These systems consisted of, initially, sixteen nodes. These nodes consisted of a disk storage node, and up to fifteen computers. Actually, any mix of computers and disk storage controllers totaling sixteen nodes. Now these computers were expensive, more like a million dollars or more than what we think of as computers today.We
Obviously, we had a lot of code that used sixteen as a number. Or more commonly, 15 since loops and arrays start at zero. These numbers were used everywhere! Everything was fine until the company announced that they were now going to support 32 nodes in a cluster. Uh oh! We spent a lot of time, weeks in fact, changing the code to support 32 nodes. It was not just a matter of doing some sort of bulk edit. Each line of code had to be examined, evaluated, changed if appropriate and then everything had to be tested completely. It was a lot of work.
We did get smart though. We defined a couple of constant variables and used these named constants in place of hard coding specific numbers. Something we should have done in the first place of course.
Later, actually several later times, when the number of supported nodes was changed again, we only had to edit a few constants, rebuild the system, and things worked very well. Lesson learned: Hard coding magic number is not a good idea. The is a real place for constants.
