Distribution & Delivery Global Viewpoint – February 2022

Television is reaching maturity in terms of its workflows and reliability. With the widescale adoption of IP, the widget boxes of the past are diminishing in number leading to more stable infrastructures. As we continue our IP journey, the probability of finding ominous long forgotten grey alloy boxes lurking under the flooring is reducing as the months and years go by. Not that these interface units didn’t have their place, but the flexibility that IP delivers means much of the connectivity is now provided in software. And here lies our next challenge.

Hopefully, most glue coding is provided by the system integrator during installation. The workflows would have been analyzed to death and the availability of APIs and accessible databases would have allowed the SI to build the perfect design. But just because we are working in the IP domain doesn’t mean the user and production requirements don’t change at the drop of a hat.

Scripting languages such as Python allow anybody with even a modicum of software experience the chance to write high quality code and solve really interesting workflow problems. Admittedly Python won’t easily allow the processing of low latency real-time video and audio, but for many workflow applications it’s the perfect glue solution.

In its most basic form, writing code only requires a simple text editor and an installation of one of the multiplatform versions of the Python interpreter. Command line debuggers are available and those looking to make their lives even easier will use one of the high-end and free (to use) IDEs such as Visual Studio, or vi and emacs if you’re feeling particularly adventurous.

It’s worth remembering that writing the code and solving the problem at hand is only half the solution. Once the new workflow is working it’s easy just to go fight the next fire and forget about the solution you’ve just found. And this is where the danger really lies. Where is the source code stored? How does it work? What problem does it solve? Which version of Python did it use? Etc etc…

One relatively straight forward solution to this challenge is to use one of the software repositories such as GitHub. This allows the developer to create a project for the software being written and document it as the project progresses. Professional software developers may tell us that code should be self-documenting, but in the main, most broadcast technologists writing this level of code won’t be professional software developers but will know enough to build high quality solutions. Their solutions may not be commercial software applications, but they don’t need to be. However, they do need to be well documented and understood.

Using software repositories is a fantastic discipline to adopt. Not only does it provide a history of all the changes to the code you’ve made, but it provides a central repository that all your colleagues can access. Wiki pages and “readme” files encourage copious note taking as the project progresses so that when you come back to it in six months, you’ll still have a fighting chance of quickly adapting the code to solve the next problem.

Not only do software repositories solve long term maintenance challenges, but they also help your colleagues understand what you were thinking so they can develop your design further.