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.
Confidence is an important factor in customer technology decisions, and release notes can have an impact on this. On one deployment, the technician told the customer, “Let’s hope this update solves the problem.” The customer had serious concerns about the product, and was considering using a different and more expensive product in a deployment that was just launching. In this case, had the technician read the release notes, he could have seen that the problem was listed under “corrections,” and informed the customer. This would have saved the customer a lot of needless worry and research. ?
Write to Ray about this column at [email protected]. Ray Bernard, PSP, CHS-III is the principal consultant for Ray Bernard Consulting Services (RBCS), a firm that provides security consulting services for public and private facilities. For more information about Ray Bernard and RBCS go to www.go-rbcs.com or call 949-831-6788. Mr. Bernard is also a member of the Content Expert Faculty of the Security Executive Council (www.SecurityExecutiveCouncil.com).
