Here are some of the lessons I’ve learned over the couple of years. I like to make up an analogy or a fake proverb to easily remember an important lesson I learned. I might have heard some of these before, somewhere, and perhaps thought I came up with it. So, I am sorry if I am unable to give credit when it’s due. While I was doing some research for this article, I came across to an excellent piece of writing. Majority of the things I wanted to say has already been explained way better than I could ever do here in this article: https://www.elsevier.com/connect/8-great-ideas-in-computer-architecture
But let me give it a try…
Build a wall so that when you hit it with a hammer it will make a hole and won’t collapse the whole structure.
This explains one of the fundamental benefits of Microservices architecture. It also helps to think about fault tolerant design.
To plow a field easier don’t make a single ox go faster, add more oxen. (until you can afford a truck).
I heard this one somewhere but can’t remember. I probably botched it too. I think this explains how one should approach to increase a systems ability to deal with certain type of computational problems (horizontal scaling). This also helps to understand the idea behind Hadoop and Spark like architectures.
Premature optimization = Bad
Simple, right? However, I always feel the urge to go ahead and refactor my code. Optimizing doesn’t always bring value to stake holders.
Elevators carry people.
This idea about “choosing your battles” when it comes to optimizing for speed performance. However, this approach requires an assumption of what the common case will be.Think about how you’d design an elevator for an apartment. I’d start with the assumption that it should have the capacity to carry humans. It’d certainly be nice to be able to carry an elephant but efforts to design and implement this capability would be wasteful.
That’s it for now…
