Variable Constants and When Things that Never Change Actually Change

One of the great learning experiences of my professional career was working on a project that would test up to 16 computers in a cluster. We were told that 16 was the maximum number and that for performance reasons that number was not ever going to change. We believed them. They were wrong. The number changed. Now the learning really began.

We had to go back and fix our code to work with the new number which was 32. It turns out that you can't just do a global chance of 16 to 32. For one thing because of off by one issues we'd used 15 in a lot of places. These numbers occurred in a lot of places. This was code that up to 7 people had worked on for over a year. We did get a little smarter of course. This time we defined a global constant and everywhere that a hard coded number was we replaced it with a reference to that constant. Why did we not do that in the first place? I'm not sure because none of my code, as best as I can recall, was effective.

In any case, when the no it is never going to change number of 32 went to 64 and later to 128 all we had to do was change one line of code and rebuild the system. Much nicer.

Rule number one: When someone tells you something will never change take that as a promise that it will change.

Corollary to rule number one: Avoid hardwired numbers and limits. Plan for constants to change.

I'm sure I am speaking to the choir here of course. You all know this stuff. I have an interesting example of constants changing that is more contemporary though. Something your students may be able to relate to. Some values are difficult to change. One of them that actually takes an Act of Congress (or the local equivalent) to change is the start and end dates of daylight savings time. Congress actually did that recently and it sure has had an impact on a lot of software. In case you are interested here is a link to a bunch of articles about how this change impacts some various software products.

Date and time issues are an example of things we don't always think about until they go wrong. Of course when they do go wrong they can go very wrong. Anyone can learn from their own mistakes but I think we owe it to others to help them learn from the mistakes of those who made them earlier. I think this is an interesting topic of discussion if only to get students and beginning programmers to think about what sorts of things are involved.

Technorati tags: DST, Daylight Savings, programming

P>