After years of building interactive installations and similar projects, I noticed that there was a lot of reinventing the wheel going on. Having diverse teams (creative coders, web developers, and designers who couldn't code at all), it seemed counterproductive to insist that everyone use the same framework, programming language or application. Every new project demanded new skills and new tools, and while I have always enjoyed learning new things, these fast-paced projects could often be chaotic. It felt like so little of our work was reusable from one project to the next.

We resolved this situation very effectively over the course of about 4 years, by creating a set of standards and tooling which came to be called Tether (available for anyone to use at https://github.com/RandomStudio/tether).

The solution was to step back and notice what was common to our work: the approach and the system architectures we gravitated towards. These kinds of installations tended to involve eclectic technology - this was both a big strength and a serious challenge - so becoming good at glueing things together was the key to increasing our productivity.

What emerged from our efforts (and I wrote the majority of the code and documentation) was a set of libraries, command-line tools and applications, written in 4 languages (C++, Rust, TypeScript and Python). It allowed us to tie together systems comprising HTTP, ArtNet, OSC, WebSockets and UDP. We were able to integrate applications based in Unreal, Ableton Live and TouchDesigner alongside our own web applications, NodeJS services, openFrameworks applications and microcontroller code.

We did the custom work where it was needed. The core, meanwhile, was based on existing technology, specifically MQTT and MessagePack.

The main benefits of working this way turned out to be:

1. We could re-use lots of code, applications and services between projects.
2. We could choose the "right tool for the job" each time, inserting a little bit of interface/bridging code if necessary to get it to work with the rest of our Tether-based systems.
3. Development, testing, setup (on site) and troubleshooting became significantly easier because everything was talking the same language and all messaging in the system was easy to inspect.
4. We could record and play back real message data to simulate complex systems without needing all the hardware plugged in.

In the process, I solidified my understanding of the challenges underlying these kinds of projects: distributed computing, state management and event-based asynchronous programming.