Earlier quoted context omitted.
I worked in similar systems and you are 100% right. 80% of the time was spent on communication protocols between the different boards and microcontrollers. QAing and solving issues from short-sighted dozens of unique custom protocols that worked in non-standard ways (every time a component needs to talk to another component a new protocol was invented). When you have dozens of communication lines required between dif…
> every time a component needs to talk to another component a new protocol was invented > We actually spent considerable amount of time just developing our own custom protocol Not only is this unintentionally hilarious, it’s a real life example of an xkcd comic ( https://xkcd.com/927/ ) that will never cease to be true. > eventually all our data communication would use a single unified protocol from micro-controller…
On the other hand it was nice being able to just import a library into your code and JUST SEND A FREAKING MESSAGE without having to deal with thousands of lines of code that were last changed 3 years ago and nobody knows how it works. The scrutiny on the code quality of the common protocol was much higher and therefor much more pleasant to use and troubleshoot.
All the encoders and decoders of messages used the same code in all the parts of the stack (technically 2 implementations, one in Go and one in C)