Craig Norris is the Technology Editor for TV Technology Europe.
Why do some people in the broadcast vendor community speak with contempt about what they call "legacy" systems? It's as though anything done "the old way" is considered to have been done in a bad way.
This contempt for the traditional methods of operation or engineering design stems from a belief that whatever is new must be better, and that the old must give way to the new — no matter what. I don't object to that basic idea, unless it is obvious to me that the new way is not necessarily better than the old.
As a freelance consultant, I get around. I get to see and hear the Operations and Engineering goings-on of many TV stations around the world. And what I commonly hear is complaints from operational staff that the new IT-based production system thrust upon them is slower, less efficient, and more troublesome than the "legacy" video-tape based operation.
Some of those complaints are attributable to a lack of training or understanding on the part of the operators. But the rest are attributable to the fact that the operators are right. In many instances, the new system is slower, less efficient, and more troublesome than the legacy system.
How could that be? How could it be that a brand new, latest technology, industry leader, cutting edge design, and every other buzz-word-adjective system, could generate so many complaints among the users?
The first reason is because the system vendor broke the Golden Rule of system design: "Thou shalt not take away any existing capability from the user." There's nothing more frustrating for a user than to find he can't do some basic function on the new system that he was doing for years on the old system. For example, a camcorder tape arrives from the ENG crew, and the news editor puts it in a player and immediately starts editing a story. But in the new system, he has to wait for it to be fully ingested, and only then can he start editing the story.
You might be thinking "That's ridiculous — all IT based production systems allow the user to start editing a story within a few seconds from the BEGINNING of the ingest activity!" But you'd be wrong. I saw a system just recently that had no such capability — and the users were very upset about it.
That brings me to another Golden Rule of system design: "Thou shalt confirm and get accepted every detailed specification of the system with the user before the contract for supply is signed." When this rule is broken, it's a shared responsibility on the part of the customer and the vendor. The customer should insist on seeing a detailed specification document, and should thoroughly study it in very fine detail. The end users must be informed of the detailed specification, and any deficiencies therein must be debated to determine whether the end users can accept such deficiencies. There are almost always deficiencies.
And the vendor must not sign the contract for supply until he or she is sure that the customer has accepted the detailed specification, including any deficiencies therein. But here lies a fundamental weakness in many vendor sales representatives — the urge to get the order no matter what, even when there are glaring mismatches between the customer expectations and the offered system functionality.
When I was at the helm of large system sales negotiations for a well-known vendor, I adopted a very firm policy of underselling the product. I made sure the customer's expectations were lower than the capability of the product that we were going to deliver. I wanted the customer to be pleasantly surprised that the product was even better than he was expecting.
The last thing I wanted was for the customer to be disappointed with his million-dollar system. I value the relationship I have with my clients. I need to be able to look my customer in the eye and always tell the truth. Only that way can I sleep well at night. But I'm sorry to say that there are some Sales personnel in some companies for whom the truth is only optional, and in some instances, the truth is inconvenient.
Stepping back from the front line sales to the engineering design of broadcast systems, I find also that some system designers, particularly those with a mostly IT background, seem to have an allergy to any technical solution that isn't a state of the art IT solution. It's like the old Chinese proverb: "To he whose only tool is a hammer, every problem looks like a nail."
For example, the broadcast industry was happily using RS-422 interfaces and cables for the real time control of videotape machines, video switchers, audio mixers, character generators, and other devices in the system. The cable was strong. The connector was secure, with retaining screws as standard. But try to get an IT system designer to use an RS-422 interface for anything, and you'll most likely meet with a stubborn unwillingness. That unwillingness is not for any good technical reason — it's just a prejudice — a prejudice against anything that's been around a long time, no matter how useful and reliable it may be.
The IT designer's penchant is for plastic, insecure, easily broken RJ45 network connections, over an interface that is not well-known at all for real-time process control. Try talking to a young IT engineer about the merits of an RS-422 connection, and you'll be met with a sneer. Us old guys with our old ways are often treated as old-fashioned. And "fashion" is a powerful force among young people.
Fashion overrides practicality. Just look at women's shoes for proof of that. And the modern IT industry is very prone to the forces of fashion. It is as much marketing-driven as it is technology driven. And that's the problem with so-called "legacy" systems. They just aren't fashionable. They still work fine. They just aren't trendy or fashionable. And that apparently is enough reason to supersede them, even if the successor system is inferior in many ways. Welcome to the 21st century!
Future US's leading brands bring the most important, up-to-date information right to your inbox
Thank you for signing up to TV Tech. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.