Recently Tim Albright, of AVNation, and I were debating about the grammar of a sentence. Yes, that is what we do when looking at the website and looking for challenges that can be improved. While I might be cranky quite often, I do not want to berate and attack people with incomplete data. I took the sentence in question and ran it through the Grammarly service. It is one of the highest rated online grammar checking sites. Sure enough, Grammarly indicated that the phrasing of the sentence was correct. The sentence in question is, “Fall of 2015 Josh Srago, Kirsten Nelson, and I was attending the national sales meeting for AVI Systems, an integrator headquartered in Minneapolis.” Grammarly indicated the word ‘was is correct, both of us thought it should be ‘were’. Changing the sentence to, “During the fall of 2015 Josh Srago, Kirsten Nelson, and I were attending the national sales meeting of AVI Systems, an integrator headquartered in Minneapolis.” changed the results. The word ‘were’ is now correct.

How does this story relate to audio, video, lighting, or control? The point of this parable is that software is very fallible. To trust software without checking the validity or sensibility of a result can often be a problem. Many of us have heard tales of GPS based computer directions gone wrong, the same thing can happen in almost any piece of software.

Many AV technicians use software packages designed for making room measurements. These are great tools to help with compensating for room acoustics and speaker performance. I have seen and heard people watch the screen of the software while measuring the room response. They then adjust the digital signal processor to compensate, using all the filter points to get the line looking like they want. It looks like it sounds great.
Then comes the listening.

The results are not very pleasing. But the software says it is right, so it must be. All of the available 256 filters were used. Does it sound good? That can be subjective but we all know that things can sound good or bad. There is the answer that one must consider the variable of where the measurements are being taken. To overly simplify, the phrasing of the overall sentence is the same as the location of a test microphone.

To me it comes down to something Steve Greenblatt and Brock McGinnis have been discussing on Twitter, experience. The software will not always give the desired result. Every so often one should step away from behind the software and listen in the run. Do not be afraid to trust your ears, eyes, and brain to verify what the software is indicating. Now if you will excuse me, my time measuring software says it is time for playoff hockey. Based on the position of the sun, I find that it is showing a reasonable time value.

In this age of collaboration there are many tools available to help teams work together. There is software to help automate processes. There is unified communications software. There is project management software. There is customer relationship management software. There is bug tracking software. I have found one thing to be consistent among all of these software packages and solutions. They are not panaceas.

Software will not magically fix all problems. A piece of software will not magically make someone efficient any more than owning a treadmill will cause one to lose weight. There needs to be a basic understanding of the processes and problems that the tool is supposed to be addressing. To lose weight, one needs to walk, waddle, jog, or run on the treadmill, plus likely modify their diet; one has to accept the weight loss process. To become efficient using a software tool the same idea applies; one has to accept and integrate the process.

I have been involved with various software integration projects and found certain things to be common within any software configuration process. It all starts with the user documenting what they are trying to accomplish. If one is specifying an audio, video, control or lighting system the first step is the same: get the user requirements and determine what they are trying to accomplish. When looking at software that same step must occur. It is not just picking the latest or coolest piece of software. If one cannot document the process and what they are trying to accomplish on a piece of paper, how can workflow through a piece of software solve the issue?

I use and leverage technology when I can for my benefit. I own and have tried various pieces of software for keeping track of things and thoughts: Dropbox, Evernote, Notes, iThoughts, Wunderlist, Clear, NoteTakerHD…and the list continues. The most effective tool I have for creating and tracking ideas is the whiteboard in my office or the notebook in front of me. I then transfer the thoughts and ideas into a digital format.

That is an important thought. Software is a tool that simplifies the analog process. It is still key to understand the process and follow it through to completion. A user needs to be aware of what the software is tracking and indicating. If an internal tool calculates, whether analog or digital, a task or project will not be completed in time it still must be communicated internally and to the client and then acted upon as the client will often not have visibility of the tool.

Most importantly, if the tool is collaborative everyone on the team has to use and engage with the tool. If not everyone is using the tool, the data it provides is not accurate and each person has varying degrees of information. If you notice I say tool and not software. The reason for that is that this idea is key whether one is using a whiteboard, a spreadsheet, a database, or a specialized software package. If the users do not engage and keep the data current the tool is worthless.

Do not confuse a software package with a solution. It is simply a tool. One can run a project in the analog domain, one can run a project in the digital domain. The process is the same in both; sharing information with interested parties and keeping the data current. Software might make it easier but it still requires discipline.