“Do you actually have anything in your resume actually relevant to this position?”, a high-level manager of an Israeli Big Tech company told me during a job interview. And then literally threw my resume on the table. It was just before Silo (2017-2021) shut down its operations, due to some financial issues meeting an unknown plague starting to circulate around the world. That’s how hard it was for me to find a job after spending the last 3.5 years on a product/system that never saw the light of day. Till this very day it’s not easy for me to answer in a job interview “what would you have done differently?”.
It is a valid question because of this little thing called the scientific method. You design an experiment, execute it, learn of its results, and design to conduct a follow up experiment. It matters whether it was a successful or a failed one, but matters less as it’s a part of the method.
So, what are the results of a perfectly designed experiment that was not completely executed, or not executed at all? In a binary world of success and failure, what is it? If it hasn’t succeeded, it must have failed. But it also hasn’t failed because we never executed the experiment.
For a while we were Albert Einstein. Well of course we weren’t Albert Einstein, because we haven’t invented anything as important as the theory or relativity. He is considered to be one of the greatest scientists ever, not only for his revolutionary revelations but because of his modesty to design experiments that would prove himself wrong.
A less known fact about him is that he thought that the theory of quantum mechanics is wrong. He designed an experiment that would prove it to be 100% correct or 100% wrong, one day when the right technology would exist which was about 30 years later. For 30 long years it was an experiment never executed. But without it, there would be no quantum mechanics today.
So maybe, just maybe, our entire work is worth something although to this very day it hasn’t seen the light of day. But maybe it will be by someone else years from now. Maybe by people who were inspired by it, by reading about it. It might be eventually beneficial to you. Because otherwise my binary thinking mind would just give up and never do anything about anything. Giving up would mean not to even write this book.
“Your work is nothing but a theory, because it was never in production”, a recurring phrase I’ve heard through the years. By my direct superiors as well. As a comeback I used to challenge everyone to a design review “duel”. If they’d find one known challenge in distributed messaging, distributed systems, distributed databases, security, reliability, scaling, GDPR that we haven’t run into and resolved – I will eat my own hat.
It was reviewed again and again by several architects. Only one named Nir Gazit, who at the time was Fiverr’s chief architect, pointed at something very specific and said “this replay concept is 100% correct, but the implementation wouldn’t have worked in the long run”. We’ll run into him later in this series. Besides that, no one would have done anything differently. Except for one architect who said during a job interview it sounds to him like over-engineering. But it was more my fault on how I presented it.
It was mostly my fault and how I presented it, because I neglected to mention our proof of concept. 30 units were manufactured and distributed across the United States. And within only 3 days after the release, we managed to stabilize physical devices far beyond our engineer’s fingers, and the entire system with it. And then it just worked, even when something went wrong during the night. It was a very simplified and minimal cut of the non-final architecture that had proven both the necessity and the expected outcome. We showed that we can make a physical device more complicated than Amazon’s Echo Dot, and as reliable as your microwave.
It was not over-engineered. Everything was done with good reasons, but also with too much time given. Because designing and manufacturing of a physical device would always take longer than any software project. When out of nowhere your project is hit with a 6 months delay, you just have the time to make things right. It was fully developed and running in production, but had no traffic. So it was definitely a feasible and viable design. It was not a theory.
For a while, it was Boson Higgs, a sub-particle discovered at CERN by the Large Hadron Collider in 2012. If it was discovered, it also means it has forever existed. If it was discovered, it means that someone knew what to look for. But to know what to look for, is first to know there is something to look for. How did someone know?
Simplifying it, there was a gap in The Standard Model. It is a physical model that explains reality itself. Or plainly put, “the math says there should be a Boson Higgs right here!”. Using models, they had correctly anticipated the outcome of the experiment, 40 years in advance. But until the experiment was done it was not a theory, it was a theorem.
A theorem according to Merriam Webster dictionary is:
- A formula, proposition, or statement in mathematics or logic deduced or to be deduced from other formulas or propositions
- An idea accepted or proposed as a demonstrable truth often as a part of a general theory
As such, Silo’s system is a theorem. And would remain a theorem at least until someone will take it as is and implement it, run traffic through it and continue to develop a system based on it. And that would most likely never happen, and if it will I might never know of it.
Past, Present and Future
When I first started this journey of writing The Change Factor, I quickly realized that I was doing something wrong. I really wanted, and somewhat still do, for someone else to take this system and go live with it. So I can finally have my peace.
Realizing it about myself, I’ve decided to do something else entirely. To have a clear mind while writing. To not think of anything at all, not about myself, the road I’ve taken, not my so-called self or ego. It is the only way I can write down everything I’ve learned, so someone else can design his own system. So they can do so sooner than later.
But for them to do so, they’ll know what to look for. They’ll need to know how to look at many topics through multiple perspectives. To combine it with what they know and what they need. For this, through this entire project, I’ve shown models and how to model. So they can work based on theorems and not theories.
Some of which were philosophical models that had been practiced and iterated upon for thousands of years. That was the basis of The Inevitable series, influenced both by western and by far-eastern philosophies. Some models are of software engineering, practiced for tens of years, the base of the Wasteful Applicative Evolution and the Change Driven Design series. Adding to those models from the field of industrial engineering, that’s been in practice for about 150 years, and we’ve got the series of Breaking Change. And also the followup book of Projection.
I’ve learned all of the above either prior to my work at Silo, or while researching for it. The practical examples are from my entire career, mostly from other companies and projects before and after Silo. Those along with quoting and referencing the amazing work of others who came before us and influenced our work..
It was all done for you, whoever you are, to better know how to better build your system. Not mine. Mine will be finally put to rest in this series. It would contain many more models and perspectives. It would contain many new ideas. It would contain the process of architecture itself.
But as Silo’s system is nothing more than a theorem, do not blindly rush to build anything out of it. Which you should not be doing anyhow, according to Uncle Bob’s Clean Coder. Be inspired, take it as an input. Make it your own. Make it into something that is an eventually beneficial solution to the problem you are facing. This is why this series is named Future Changes. You are the future.