I’m not a fan of arguing with people, but I cannot deny that it does have some educational value at times. Over the years I’ve learned there are many fundamental truths of the universe, and this is one of them:
> There is ALWAYS someone smarter than you.
This truth is one of many things that help to keep me in line on a daily basis, and I’m far from shy when it comes to admitting when I’m wrong. I’ll even laugh at how stupid some of my ideas truly are, once it finally sinks in… But if you live on a mountain in the middle of nowhere and have nobody to share your dumb ideas with, you have nobody to argue with. And if you have nobody to argue with, how do you discover just how terrible an idea actually is if you can’t even test it?
Simple. You just go online, share your idea and then start an argument with… yourself. Because you have no social life in any sense of the word, so this argument takes place in your head while you’re having a smoke in the back room after reading the first six chapters of ‘Journey Into the Darkness’ for perhaps the 100th time, correcting the odd spelling error that was somehow missed by the spell checker and also YOU for the first 99 times of reading it, noting all the weirdly missing spaces which were also somehow missed the first 99 times, and realizing just how bad the writing is and wondering if anyone else is even reading this needless drivel…
Which brings me to the actual idea and why it was so terrible. If the official documentation is any clue, it’s (apparently) very hard to explain, which is unfortunate because I’m the one who wrote it and even I can’t make sense of it. But I’ll try to distill the essence as much as possible, because I really don’t want to waste any more storage on a full copy of the documentation or code, or to waste anyone’s time by having them try to decipher what I was trying to say.
Basically the idea revolved around home automation, and it relied on a sort of distributed computing model in the hopes of reducing the number of possible single points of failure. So if one node fails the system keeps going because there’s another node to pick up the slack. There would be a server daemon which controls the entire system, and a bunch of software and hardware clients to sense the world and interact with it, as per the commands from the server. You could plug in a sensor and use its output for just about anything, because that one sensor can be shared by a number of otherwise unrelated processes. However, it didn’t take long for me to realize that by design, this system was doomed to fail from the start because the supposed benefits of reusing hardware actually introduces MULTIPLE single points of failure… but it took several years to realize what this design resembles, and THAT is what makes it truly terrible.
## Argument
Suppose you’re deaf to high frequencies and can’t afford hearing aids, so you buy an old fashioned fire bell that runs on a 12V DC power supply. It’s loud and (more importantly) produces a lot of noise at the frequencies that you can reliably hear. This bell could be wired to just about anything, and because there’s this epic distributed automation thing, you decide to plug in a smoke sensor, a Carbon Monoxide sensor and even a couple of flame sensors just to be sure there’s actually a fire. The software is programmed with a rule that says “ring the bell if there’s smoke and flames or Carbon Monoxide”. OK, cool.
But now you’re thinking about a full perimeter security system to alert you when there’s a trespasser on the property (or in the house). You have motion sensors, so you plug those into the system and program it to ring the bell when something moves. But why stop there? We could ring the bell for all sorts of stuff! Is the computer’s CPU running too hot? Ring the bell. Can’t get up in the morning? Write an alarm and ring the bell. Can’t hear when someone is knocking at the door? Put a button on the door, it will log the number of daily visitors you don’t get and will ring the bell. Whatever you desire, there’s a way to make it ring that bell…
## Counter Argument
But what happens if the bell stops working? What if a mouse chews on the wires and causes a short? Suddenly that guy who comes to steal your tools is back, but you don’t know this because the bell isn’t ringing. And now there’s an urgent message at the door, but you don’t answer because you think it’s just the pounding bass from the sub-woofer and the bell isn’t ringing. And because you’re falling asleep at the desk, you can’t see the hundreds of blinkenlights on the hardware console that would show you the state of the entire system, such as the fact that the bell isn’t ringing. And you can’t hear the tool man breaking a window and screaming your name because your music is just a little too loud and the bell isn’t ringing. And now the fire started by a shorted power supply has been burning for over three minutes, which means it’s engulfed an entire room and is hungry for more, so there’s no putting it out now because THE MUTHERF#!KING BELL ISN’T RINGING!
## Conclusion
And when this hypothetical horror story of a counter argument finally reaches the inevitable grim conclusion, it dawns on you at last: that epic automation system based on distributed computing, the automation system that seemed like a brilliant idea at the time, that very same automation system you spent months designing, writing the code for, buying hardware for but never actually built, could in fact be far more harmful than helpful.
And while redundancy is a core part of the design and could easily prevent this hypothetical horror story, the fact that it relies on a CENTRAL server daemon to control the ENTIRE system (failure) comprised of many components that SHOULD be separate and independent but aren’t, means it’s the equivalent of systemd written in less than 700 lines of Go… and there is nothing funny about that.
