2021-04 IT in AV
To Code or not To Code?
James King
This month's theme, Emerging Technology, can be taken in many different directions. We have voice control, AI, VR, and AVoIP just as some of the emerging technologies that schools are looking at. I could take this article down one of those rabbit holes but I thought I would tackle something that all of those have in common and that is the programming of our AV equipment. Now I don't want to bore you by writing about: configuration vs programming, HTML5, python, or diving into the weeds of coding. This article is geared more toward who should handle the programming. Schools have options of either using an integrator, a third-party programmer, or hiring an in-house programmer. Each option has its pros and cons and I hope this article will help tech managers make the best choice for their school.
Integration Company:
One way that AV programming is being done is to have an integration company handle it, which can take the load off of the school that may not be able to allocate resources to programming. This allows the tech manager to focus on other aspects of their job knowing that they are getting a turn-key solution. A turn-key solution helps speed up the project as the integration company can work on the code, with the equipment, back at their shop before even stepping foot on campus. The integration company can work out the bugs and issues in their shop which would mean less time needed onsite to address programming. Another benefit to having an integration company handle the programming is keeping up with the latest programming languages, tips, and styles. As more AV equipment is moving to traditional IT infrastructure so is AV programming. This requires the person programming the AV equipment to know the latest information coming down the pipe.
One issue with having an integration company handle the programming is trying to keep a consistent feel across our rooms. We cannot always guarantee that we will get the same integration company for every project and even if we could guarantee the same integrator we cannot guarantee the same programmer. Having a different feel in every space can cause frustration among users, as well as become a support headache when trying to recall which UI the user might be looking at. Another disadvantage of letting an integrator handle the programming is that their programmer doesn't always have a connection with the end-user. There are things that our faculty members prefer that might not make sense
to an outsider but makes sense to someone who has built a working relationship with the end-user.
The last aspect I will address about an integration company is an endless debate, mainly during #AVintheAM discussions, about who owns the code. Ownership of the code can be spelled out in the scope of work, a contract, or not at all. Although, even if it is stated that the university owns the code, doesn't necessarily guarantee that the integrator isn't reusing the code for other projects or even that the code they provided for you didn't come from another project. If you do not own the code and need to switch integrators or even decide to bring the coding in-house, you will need to start over.
Third-Party Programmers:
When it comes to third-party programmers you might be thinking 'are they not the same as an integration company?' In some ways they are like an integrator company but in many ways they are not. One advantage that a third-party programmer has over an integrator is that programming is their primary focus. With them solely focusing on programming, it allows them to improve their skills and keep up with the latest programming languages, styles, and tips. As mentioned above, AV programming is taking advantage of traditional IT programming which in turn is more software development. With the move to a software development mindset, programmers can use
the flexibility of modern computer programming languages, like Python, C-Sharp, and HTML5. Having an understanding of these modern languages provides the framework to allow their code to run on multiple devices and extremely scalable depending on the devices it’s pushed to.
Another advantage to a third-party programmer is that schools can justify them as a sole source. With the third-party programmer being a sole source, it allows the schools to keep a consistent feel across all spaces. This also allows the school and the third-party programmer to build a working relationship allowing the programmer to have a better understanding of the end-users and their needs.
One issue with going with a third-party programmer is that you are now adding another element to the project to be managed. The project manager will need to make sure the integrator and the third-party programmer are working together and meeting the project's goals. Also, because third-party programmers are not installing the equipment, they may not be able to test out their code ahead of time. This means the programmer will need to address any bugs or issues after installation which can lead to a longer project timeline. Also, if an issue is discovered then it becomes a matter of finger-pointing and trying to figure out the issue and who should fix it.
In-House Programmers:
Having an in-house programmer means there is no worrying about who owns the code. When the school owns the code then little changes, like a UI update, can be done easily without incurring additional cost or having to find the time for an outside person to update it. Another advantage is that it is easier to keep a standard feel for all spaces because you know who the programmer is and they know what the other rooms are already doing. With an in-house programmer, they can also build a working relationship with the end-users to make sure their needs are met as well as make it easier to figure out where issues are.
A disadvantage of having an in-house programmer is unless you have a team, the programmer becomes a 'person on an island.' Being the 'person on an island' the programmer is limited in their resources. They may only know the current AV programming language, which means if the school wants or needs to change manufacturers then the programmer needs to learn the new language. With this in mind, a school might be more hesitant to change manufacturers even if it would be best. There is a saying “code doesn't just break” which leads to another disadvantage of an in-house programmer. With code not breaking then an in-house programmer is going to have downtime. This downtime can lead to other duties being assigned to their programmer. With programmers handling other duties they may not be able to keep up-to-date on the latest programming tips, styles, languages, or even address minor updates in a timely manner.
Conclusion:
The above information is just some information to help tech managers make the best choice for their schools. With my background in IT and my understanding of programming I became the in-house AV programmer for my university. Just because my school feels having an in-house programmer is the best option does not mean it’s the best option for your school. Each school has its challenges they face but the tech manager needs to make the choice that fits their needs so they can continue to provide the best learning environments for their students
Meet the author: James King
James King graduated from Stockton University in 2008 with a Bachelor's of Science in Information Systems and a Minor in Business Studies. After graduation, he started working full time for Stockton's IT department and in 2012 was assigned to support the classrooms' AV equipment. Since joining the AV team, he has continued his education by getting AV certifications as well as working on getting his MBA. Besides working at Stockton, he is also a member of the AVIXA Technology Managers Council, manager of the HETMA award-winning Higher Ed AV/IT Slack workgroup, the current president for Pinelands Soccer Association soccer league, co-coach of a travel soccer team, and a goalkeeper trainer.
