“Trust but verify,” the cold war adage, has been invoked in many different ways over the years. Sadly, its applicability to IT goes beyond just concerns of e-mail viruses. Network executives, it would seem, have to be concerned with real products that come with imaginary features.
In recent months alone, without really looking, The Tolly Group has encountered several leading products that have come down with “imaginary feature syndrome.” Here’s how it has typically played out:
In the course of evaluating a product, our engineers enable or configure a service on the box, but the test results don’t change. After verifying that the configuration steps were correct, we contact the vendor’s product support staff. A short while later, the vendor support staff informs us that the implementation is “not yet complete.” Translation: The feature doesn’t exist.
I understand that software development is an ongoing affair. What bothers me – and strikes me as disingenuous on the vendors’ part – is that they manage to finish enough of the development to let you think that the feature exists. You can click away and configure the feature – it is up to you to find out that it’s not there. And this is not always easy.
In one instance, the test involved quality of service (QoS) for a new, high-speed LAN module. The test attempted to exercise a long-advertised QoS capability using new hardware. It didn’t work.
The vendor told us that this support had not yet been ported to work with the new module. At the same time, we were informed that customers knew that. We couldn’t find any such notice on the vendor’s Web site. After so informing the vendor, a document miraculously appeared.
A much simpler evaluation of QoS in an IP telephone led us down the same path.
If we’ve learned anything about convergence these past few years, it is that latency-sensitive, real-time interactive voice needs to be prioritized above other traffic. Thus, evaluating QoS tagging on voice-over-IP (VoIP) endpoints is a basic, essential task.
During a test, our engineer dutifully was exercising the system’s ability to set any one of multiple priority levels on the phone’s VoIP traffic stream. But, when we pulled up the actual network traffic on the trace, something wasn’t right. No matter how we configured the priority on the graphical user interface (GUI), packet priority remained zero.
After verifying that our network analyzer wasn’t at fault, we contacted the vendor, which quickly acknowledged that this feature was implemented only partially. Again, the vendor managed to implement the part that lets you think the feature exists but hadn’t gotten around to setting the proper bits in the packet. Nor had the vendor bothered to update the message on the GUI to remind network managers that while they could configure the feature, the phones did not yet support it. Simple oversight.
So why does this happen?
Often, it is the drive to be “first to market” combined with the mostly accurate observation that while network managers will buy a product because of its bleeding-edge features, they rarely will use those features immediately. Thus, as long as the basic claim can be satisfied, many of the more subtle aspects might not be exercised for weeks or, more likely, months.
So like a good cold warrior, remember always to trust but verify.
