Creating a control system program for an AV system is a lot like any kind of software development. Although the techniques may be slightly different, there are a lot of things that our industry shares in common with computer programming in general.

Or should share in common.

You see, a lot of times as AV integrators it is easy to skip a lot of steps that our programming brethren have identified as best practices for developing software applications.

As a programmer in this industry, you really have to wear multiple hats and that makes our jobs a bit more challenging than just writing code. Realizing the different roles you have can make it easier to navigate the challenge of programming an AV system and provide your users with a much more stable system.

AV Programmer Hat #1 – Market Researcher
Typically before a “normal” software project is undertaken, there is a lot of time spent trying to decide what problem needs to be solved and what kind of a solution can be provided. In AV terms, you already have the problem defined – a simple way to control complicated equipment. Always keep this idiom in mind as it will help guide you to create a solution that actually meets the core need. If you have the opportunity, it is nice to get a feel for what the end user actually wants the system to do. How do they use the equipment, and what kinds of things can you do to make it simpler?

AV Programmer Hat #2 – User interface designer
The key to a good program is in its interface. It doesn’t matter what is under the hood if the system is difficult to use. A user interface should give users a intuitive way to accomplish a task without having to go through any more steps than necessary. I’ve seen a lot of programs where this approach was not followed and what resulted was basically many pages of equipment remotes. Keep in mind that the average user does not care to learn how to operate a complicated piece of gear like a matrix switcher and may be better served with presets that give them a configuration that they want. If more advanced control is required for technical people, you can always add an advanced menu but the default should be simple and straightforward for anyone to be able to walk in and operate the room.

AV Programmer Hat #3 – Coder
Most people are familiar with this part of the project. Having robust code that doesn’t get caught in undefined conditions can go along way to making the system reliable, which prevents service calls. Before you start writing code or dropping in logic symbols, you need to have a general plan of what your system will do. If this step is missed, the program will end up as an unmanageable mess of hacked-in features. You also need to find a balance between over engineering the code and under engineering where it is impossible to add a bit of additional functionality without major changes.

AV Programmer Hat #4 – Beta tester
This could be one of the most time consuming aspects of the whole job as you need to go through every combination to make sure things work properly. If you are working wi projectors, you have to deal with the dreaded 1-3 minute cool down on every power cycle which can make testing entire system functionality tedious and painful. Working out the bugs now means you can fix the problem so it doesn’t require a call back later on.

AV Programmer Hat #5 – Maintenance programmer
One of the best reasons to plan out your code is for this phase of the project. Invariably the users are going to want to change something or add a piece of gear. Your code should be easy to understand so that another programmer down the road can pick up where you left off.
If you can successfully wear all hats through a project, you will end up with a much more stable system, happier customers, and repeat/referral business.

We’ve just scratched the surface here with this topic. What are some of the other ways that you have noticed where traditional “AV programming” has missed the mark of providing value? (We like to hear stories too…feel free to tell some horror stories!)