How to Effectively Repurpose AV Control Programming
It’s a known fact that programming carries the label of being time consuming, tedious, and challenging. Thus a working system that is well-programmed has a lot of value. Those who invest in developing code not only want to know they own it, but that they can leverage it to get the most value for their investment.
Some would say that programming costs become more palatable with the ability to take code from one system and apply it to others that are similar. It makes sense that similar systems requiring only slight modification should stem from the same source code. Along the same lines, code for a system that represents a subset of a larger system can be built upon to support additional applications or capabilities. In all cases, the argument of a client only paying for the changes from one system to another could be used, presuming that consistencies are strictly maintained. This approach is most effective when planning and developing code that is purpose built for a specific project or client with the intent of reuse.
Others may look to repurpose the same or similar systems as a preprogrammed package by leveraging the base programming that was written for the first system and reusing or modifying it for each subsequent system. While this strategy makes sense and can be a lucrative model, it should be approached properly and handled carefully.
Each time programming is reused for a new application or client, revisions are made likely resulting in new, unique instances of code. Whether it is little things like room name, room phone number, number of sources, naming of buttons, or larger needs like changing make/model of equipment and adjusting system operation, the code that may have been tested and verified in its original form will take on a new unproven state. Depending on the impact of the changes, the entire system may need to be re-tested and validated to avoid a potential quality control challenge. It should also be noted that modifications made by brute force rather than the finesse of the original developer can run the risk of damaging the sturdiness of the once rock solid original code for the initial system.
All programmers look to reuse code they have taken effort and care into developing and knowing how it works. It is human nature to not “reinvent the wheel” when something can be repurposed to save time, money, and provide efficiency. However, it is important to be responsible in this strategy. Writing code that is intended for one system and reusing it over and over again for other needs can present problems down the road. Although repurposed code may satisfy the immediate need of getting a system working or getting a project completed on time and under budget, challenges will be presented as other programmers attempt to modify code that is not purpose built. Everything from commented out functionality, to dead end logic paths, to misleading documentation, to inefficient coding style, to instability in performance can play a factor when someone unfamiliar with the code attempts to update or modify it in the future. Depending on how much the code been repurposed and how much time has passed since it was last updated, its integrity and effectiveness can be severely impacted leading to the inevitable need to do a complete re-write. What was once a well-crafted program becomes degraded each time is it modified and reused. It is similar to the days of analog tape duplication. Making a copy of a copy lowers the quality and effectiveness with each generation.
When writing code with the intent of reuse, success comes in taking an approach that effectively supports modifications and scalability, and following best practices. Here are some guidelines to avoid pitfalls and achieve that success:
Design The Solution Before Developing the Code
For most systems, including those that are bespoke, it is important to understand the requirements of the system and think through the solution prior to programming. This entails not only defining the system functionality aka “business logic,” but also knowing how this system fits into a bigger picture and what other systems complement this one. By identifying the elements that are likely to change in the future such as make/model of displays, quantity of inputs, the addition of sub-systems for conferencing or environmental controls, etc., code can be written in supportive manner. This also applies for anticipating future needs, so that ground work can be paved for expansion of functionality and equipment such as planning for a second or third display in the system.
Specify the System Elements that will Vary Upfront
Every system contains unknowns or elements that will vary based on system particulars, device settings, installation requirements, and user preferences. These can include IP addresses, lighting presets, source names, room names, timing adjustments, or automation settings. Building in the ability to adjust these elements from a technician interface in the field, without the need to modify code, will reduce the number of code revisions substantially and limit the amount of one-off programs. The more items that can be adjusted outside of modifying and reloading code, the more effective the solution. When clients have the ability to make their own adjustments without the need to update code it will not only lead to greater satisfaction, it will also reduce the amount of service calls, reduce costs, and increase response time for their users.
Architect the Software Solution
Programming can be done in an infinite number of ways, especially when forethought is not given to the need to modify, scale, or be easily supported by others. In some rare cases, these needs are not a factor. However, in most situations well-written source code should be crafted in a manner that others can understand, implement, maintain, change, or upgrade. With this in mind, writing modular code that can be changed or swapped out without impacting other aspects of a system is critical. Modular code serves to minimize the risk of revisions to one aspect of the system impacting others. It also affords software developers the ability to work on isolated components of a system separately and simultaneously, if needed. While some software developers tackle device control and complex communication, others can focus on user operation and system functionality without the concern of disrupting each other’s work. When changes need to be made in a modular design they can be compartmentalized, limiting the risk of degrading the overall code.
Repurposing programming is a sensible and effective approach for any software developer, integrator, or end user. It can promote greater outcomes and more value by spreading costs across multiple applications. It also allows more to be done in less time creating efficiency and margin. Like with any other business strategy, an effective approach needs to be implemented to get long term results. Taking the time to develop code that is well thought out and responsibly repurposed will yield greater benefit to the client and the developer. Although the success of an isolated project or one-off system can’t be closely tied to the quality of the source code, its importance is magnified when plans call for reuse and replication. What may seem to be a solid foundation for limited usage may quickly be exposed as requirements evolve. To truly be successful, repurposing of source code needs to be planned from the onset rather than implemented as a convenience.
To learn more about AV Control System Programming, check out Control Concepts’ services & solutions.
