Thursday, February 11, 2016

Planning for the Rare Cases

I had family in town recently and we visited the park in Great Falls, Virginia (USA). This is an area of waterfalls on the Potomac river and there are several observation points, situated at least 15 ft. (5 m) above the water flowing over the rapids/falls.

There is a rather interesting exhibit showing the level of various floods that the area has had:


Considering that I (with the beard) am 5 ft. 10 in. (1.78 m) tall, you can see that there have been some very deep floods in the past.

So, when you are planning in that area, what do you plan for? Most of the time the water is far below the area of the park. 20 years ago it was almost to my waist for a few days. 44 years ago it was over my head and less than 100 years ago it was more than twice my height. What does it cost to repair damage for something built too low vs. building it to survive for 20, 50 or 100 years? Not easy decisions.

In programming, we face the same choices: How much time and effort do we expend to handle those outlying cases? Do we really need good error checking and messages for something that will very rarely happen, if at all?

A colleague of mine told me the story of working in a radar installation when one of the technicians spoke up and said, "The radar is sick." When queried as to how he knew that, he replied that it had told him. Sure enough, there was an error message on his screen that said, "I am sick".

Further investigation revealed that when a programmer was given the set of status codes that the radar hardware could return, he asked what to do if he got something other than those codes. He was told, "Don't worry about it, it will never happen.". Unless, of course, something was unplugged and random signals were being induced onto the wiring as in this case.

I suggest planning for as many of the worst cases as you can, just in case your system gets really sick. 

No comments:

Post a Comment