Keep it simple, stupid
Hey, yep I’m still around. I am working on different articles and projects, I am pushing a lot at work because is appraisal time and I am also on diet. But still, late, I’m publishing.
If there is a religion, even a calendar is enough, that starts on February I am ready for commit myself to it because I cleared my mind only recently on starting a “pilot” about managing my “to read” list.
I will consume my to-read list and I will take here the most interesting resources that I will encounter.
The first two resources that I want to bring here are one article from Addy Osmani (Eng. Lead at Google) “Stick to boring architecture for as long as possible” and the manifest of “The Frugal Architect” by Werner Vogels (VP & CTO at Amazon.com)
Topics are different but I can see a subtle connection line: the simplicity.
You don’t need to jump on the new tech or new architectural approach to show that your company (or you…) are up-to-date and technically on the edge. Being with the latest tech-stack or implementing an over-engineered architecture for no reason is just wasting resources, means nothing and tells the opposite about you (and your company) than what you want.
Programming languages and architectural patterns/designs are ways to reach a goal, solve problems; not the main purpose of a pointless showoff.
Analyze use cases, cover them with known tech if possible. Identify soft spots, stick to the easy solution. Start small, Build, Think and Iterate.
Keep the Value as North Star
Start from the problem and the situation that you need to handle. Focus on how to solve it and not allow yourself to scatter your energy in the rabbit hole of the newest technology. Use the building blocks that you know: if you miss one of them about a particular solution, choose the most popular one, with the widest documentation possible.
As Addy says, we as engineers are thrilled to use the newest toy, the novel solution. The value of us as engineers comes out from the critical thinking that guides us to choose what solves our use cases and now what is the most exciting shiny thing. Stay updated about the emerging technology but don’t use it just for the sake of using it: it only leads to needless complexity, technical debt and more effort in maintenance (I feel you, single node, self-managed Kubernetes cluster for a prominent startup: you won’t get all that traffic, rest in peace).
We can find the same topic in the Laws of the Werner’s manifest: balance features and time-to-market, that means value delivering (Law I).
Don’t reinvent the wheel
Frameworks, libraries, well-architected patterns are right there, search for them. Hardly you are facing a new problem for the first time, don’t be worried about asking around or searching for pre built blueprints of solutions. You will find out that you will be called to solve a lot of others challenging and interesting problems during down the path so, at least, try to start following an already know path if possible. You wont get bored, I can promise you.
In Addy’s article we find different advices about the fact that sometimes we engineers try to express our creativity with our solution proposal: just remember that the solution should be the simplest one and that our efforts should be focused on building resilient pieces of technology that a potential customer can easily use and is willing to pay for.
Werner speaks also about the other side of this topic: continuosly question what worked in the past, “we’ve always done it this way” is a dangerous statement. Apply what you know and your experience but always remember to question them (Law VII).
Iterate over it
Done is better than perfect. Perfect does not exists, tradeoffs do. Start with the simplest solution possible and iterate over it to solve the soft spots. Keep a clear list of things that can go wrong and prepare a mitigation strategy for each of the points.
The “Innovation Point Principle” that Addy quotes is a good example on how you should challange yourself before adding a new tech to your architecture: imagine to have one single point to invest in a single piece of tech. What gives you the most value, what can improve your solution more? Are you persuaded to pay your point for it? Doing this one time for every iteration should be a good pace. And this, quoting Addy is “start boring, then strategically innovate”
From Werner’s writing: every decision comes with technical and business trade-offs, remember to regularly re-evaluate them (Law III).
Closing up
The article from Werner is a more cost-oriented talk, the one from Addy instead takes a wider approach but, in the end, they are bot a set of Golden Rules that you would like to keep in mind when is your call to solve something or even challange for good other people’s solutions.
I hope you like this “more light” kind of articles, it’ easier for me to manage them but fear not, I am still working on bigger technical articles 😊 …just give me time and you won’t be disappointed!
Thanks for reading and see you next time! 😉
Lorenzo
