In the 1971 movie “Dirty Harry”, Clint Eastwood plays a tough, street-smart cop. In the opening scene, he coolly stops a bank robbery by gunning down the bank robbers with his enormous, long-barreled, Smith and Wesson .44 Magnum handgun. Shots ring out and only one robber is left, wounded. Harry walks over to him and utters the phrase that has become the signature line for this movie. “I know what you’re thinking. Did he fire six shots or only five? Well, to tell you the truth, in all this excitement, I kinda lost track myself. But being as this is a .44 Magnum, the most powerful handgun in the world, and would blow your head clean off, you’ve got to ask yourself one question: Do I feel lucky? Well, do ya punk?” The punk then surrenders, and asks Harry how many shots were left. Harry points the gun at him and pulls the trigger. The gun is empty. The bank robber was lucky.

Do you rely on luck to ensure that your mission-critical applications continuously serve your enterprise, day after day after day? Or do you have a set of pre-release test procedures that ensure that they behave exactly as intended? I ask this question because lately, I’m getting questions as to whether it is necessary or advisable to rebuild an application when upgrading the release of the operating system. You may not be required to rebuild your application but I advise you to do so, whether you are using Windows, Linux, VOS or OpenVOS. While the vendors of these systems go to great lengths to ensure that their new releases are compatible with existing code, I still think that the safest course of action is to rebuild and retest your software on the new release, and not rely on luck.

When you are running a mission critical application, I believe that it is mandatory to make this level of investment. Otherwise, like the scene from the movie, you risk exposing your business to some truly unpleasant consequences. The question that you have to ask yourself is the same — Do I feel lucky? With all the changes that are happening — new system code, perhaps a CPU upgrade to a faster processor, perhaps a few application changes — how can I be confident that nothing will go wrong?

The answer is to create a careful set of qualification tests. By rebuilding your source code on the new release, you will pick up the compiler and runtime bug fixes that are available. You may find that the compiler has some new error messages that reveal latent source code defects. By re-running your unit-level tests, you can be certain that the functional aspects of your application still work as planned. By re-running system-level tests, you can be sure that everything works together. Finally, by running a series of capacity or stress tests, you will know that the entire suite of hardware and software can handle the most severe loads you can throw at it. Plus, you will have a measure of the maximum throughput of your application, and can use this figure over the coming months as an indicator for how much spare capacity remains available.

Whatever you do, don’t fall into the trap of believing that because you didn’t run into any issues on the older release, or on the older, slower hardware, you won’t find problems when you upgrade. Our own internal statistics show that software defects correlate with increased processor speed. Problems that were unheard of, or simply rare, can become commonplace on a faster processor. Software that works for years can easily break when the normal growth in transaction volumes leads to queue overflows. The only way to know that your applications will work properly in the changed environment is to conduct as realistic and as comprehensive sets of tests as you can muster.

Don’t find yourself staring down a gun wondering how many shots are left. Don’t take chances with a mission-critical application. Don’t rely on luck. Stay in control of your situation. Find issues in your lab, not in your production environment.

If you follow these steps, you can relax after work hours, knowing that you have done your best to ensure that your systems work smoothly. Perhaps you’ll even have time to go see a movie.

That’s all for now.