This July 18, 2017 AVIXA blog by Steve Greenblatt is very well written and gives a bit of insight into the role of the AV programmer.
Find it online here.
With the rise of “no programming required” solutions, the term “programming” is becoming a bad word. In the AV world, programming has become associated with the notion of being complex, problematic, costly, and time consuming. The perception of it being difficult to implement and manage has also started to surface. While some of these may be true at times, the concept of programming and the involvement of a programmer in a project should be given some more consideration.
When thinking about programming, we usually think of writing code by a highly trained programmer using tools that may or may not be understandable by the average person. This mystique is what becomes the challenge, as the owners of the systems feel they are being kept in the dark with the inability to make modifications, or provide support without the involvement of the programmer. As a result, the negative perception of programming is created.
Whether you call it programming, configuration, or drag-and-drop application, the goal is the same — creating system functionality and automation and using technology to support an organizations’ communication and business operation. Identifying needs and providing consistent, reliable, and personalized solutions is key. Thus, it is the role of the programmer that is a critical component in achieving the desired outcome in a project.
The task of programming starts well before any “code” is written or any system is configured. Every automated system should begin with defining the system operation, establishing a user interface look and flow, and ensuring the device selection and system design support the needs of the users. These initial steps are part of the planning process and are more critical than the actual implementation phase, known as system programming.
If the intent of the system operation cannot be accurately documented (in fact, the system operation should be what defines the system design and device selection rather than the other way around), the outcome will likely not meet expectations regardless of what programming or configuration method is chosen. This concept is comparable to building a house without a blueprint. It doesn’t matter how good your tradesman, they are likely not going to succeed in meeting the expectations of the client. This is a step typically handled by a programmer as they are the ones managing and implementing the project, as well as validating the completion of the desired operation. As a result, a programmer should be considered an integral part of a design team.
The added value of a programmer does not stop there. Programmers have the responsibility of making everything work whether it is programming-related or not. For example, a programmer is relied upon to be the troubleshooting expert when something isn’t working. Therefore, they must possess knowledge about signal flow, RS-232 and IP communications, network configuration, and any products that are made by control system companies as well as third-party devices. If a function or device is not operating properly, a programmer is typically involved in figuring out the solution.
Taking it one step further, when a project is complete and an issue arises that requires troubleshooting, the programmer is typically involved to help isolate the problem using their comprehensive knowledge of the system and ability to understand how each device operates.
Although it may not be obvious to those looking in, the programmer’s role is clearly not just about programming. Whether it is creating traditional code, configuring the control system, or using any other type of drag and drop interface, involving a programmer’s expertise is critical to the success of the entire project.
