This month’s question relates to the handling of security system device updates:
Q: We’ve had a persistent problem with one of our security products, and the integrator’s technician called saying that he wanted to install a new release of the software to see if it fixes the problem. The IT person who helps support our deployments asked, “What did the release notes say?” He replied, “I’ll find out.” Her eyes practically popped out of her head. Why would she have such a strong reaction? If it is that important, why didn’t the technician read the release notes before calling us?
A: It is not surprising that she would be concerned. It has long been standard practice to review the release notes BEFORE making the decision to install an update. Failing to consult the release notes before deciding calls into question the service technician’s qualifications.
Our IT readership is probably very surprised that I have written about this, and I probably wouldn’t have; however, I recently encountered two security system deployments where updates had been installed without consulting the release notes. On one hand, I’m sure most security system technicians consider this to be a “Software 101” topic; yet, looking into this more closely, I found a number of projects where the release notes were not being read closely enough. Worse, sometimes they were being read only after installing the update; and sometimes not at all.
Software and Firmware Release Notes
Most security technology today is “intelligent technology” — which basically means, from the perspective of this column, that it contains updatable computer code. That code will be firmware or software: Firmware is code that stays in its memory chip even when the power to the chip is turned off; software is code that has to be loaded into memory again each time the device is powered up.
Release notes from the manufacturer should accompany every new version or update to the firmware or software that is released to customers. A release note is usually a text, Word or HTML document that provides information — usually in bullet lists or numbered notes — about what changed in the software.
Davin Ganroth, Vice President of User Experience for Covenant Eyes Inc., wrote an article on writing release notes when he couldn’t find any published “best practice” on them (http://blog.davingranroth.com/2010/03/how-to-write-release-notes). This is a good reference on what you should find in a release note. If you find that a manufacturer is not providing good release notes, please refer them to this article. If you don’t, then do not complain the next time you get a bad release note from them!
How to Read Release Notes
When troubleshooting a problem, two specific release notes should be studied: the release notes for the current version that’s installed, and the release notes for the recommended update. It helps to know if the problem you are dealing with has already been found, by virtue of its inclusion in the “known issues” section of the current version’s release notes. Then, look in the update’s release notes and see if you find it listed under “fixes” or “corrections.” If not, then you should contact the manufacturer to find out if the fix is planned for the next release. If so, then you probably want to wait for the next release since that that’s the one that is intended to fix the problem.
If the problem you are experiencing is not listed as a known issue, then the prudent action would be to file a trouble ticket with the manufacturer or use whatever official reporting mechanism exists. I mention this because I have found several organizations that don’t file reports on product problems — either directly or indirectly through a systems integrator. They just wait for the next update to see if that will fix the problem, which is a lazy approach that’s in no one’s best interest.