Nope, this post is not supposed to talk about how you should program a KISS class for two Cod fish avatars touching their lips in the Metaverse (but let´s not close the door here... seems like a great idea to pursue in the future!). Also I too love the band but nope number [2], we are not here today to talk about Paul Stanley and the KISS band licking the fish. If you came here for those reasons I´m sad to see you go!
If you are here to read about the design principle that was created in the 60´s by the US Navy (KISS) and one of the the most important things you should quantify in product development (COD) you came to the right place!
KISS is an acronym that has many variations but according to wikipedia (so it must be true!) it was originally transcribed by Kelly Johnson as Keep It Simple Stupid.
The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication available to repair them.
The acronym has been used by many in the U.S. military, especially the U.S. Navy and United States Air Force, and in the field of software development.
Excerpt from Wikipedia (so it must be true! [2])
If you want to go deeper on the KISS principle for software development with code examples I recommend the below articles:
- A detailed explanation of the KISS principle in software
- Best Practices in Programming Based on SOLID, KISS and Personal Experience
I honestly don´t know why the KISS acronym got the attention from the software development community (maybe the usage of profane language?) because there were many others "inspirational quotes" through the history talking about being simple, making things simple and avoiding complexity. My favorite one is from Leonardo da Vinci: “Simplicity is the ultimate sophistication” and oh boy, keeping things simple is hard. We love to complicate things.
Gregor Hohpe has a "law" that talks about complexity which nails it: "Excessive complexity is nature’s punishment for organizations that are unable to make decisions". This is another true story and how I had to remind myself about the KISS principle when I was thinking about putting this blog together while deciding what to do with my technology stack.
Where should I start.... well from the beginning dooohh!
It was 2018, a cold night in Curitiba, the only light in the room was coming from my phone while I was reading a tech blog somewhere when an article about Flutter appeared. I must admit... I failed... and... I felt in love with a technology! Wait a second... I said that falling in love with a technology is a problem in the previous Features post! Yes... I said it, which means I´m guilty! 😬️
The promise of having one codebase and the ability to ship applications in multiple platforms (at that time, the focus was mobile only: android and iOS) hit a nerve somewhere in the IT architect that lives in me and wants to optimize stuff. Sure, we already had some cross-platform development options out there like Apache Cordova (bought by Adobe), Xamarin (bought by Microsoft) or React Native (made by Facebook) but Flutter (made by Google) felt different. Maybe it was the subtle but yet very important difference on Rendering that offers comparable performance to native frameworks that caught my attention at the time.
During that passion time, I created my first mobile application using Flutter and I really enjoyed building it as a Proof of Concept (PoC). I remember thinking "oh boy when they release web support this will be AMAZING! Imagine with one codebase being able to publish to mobile and also to the web with Flutter!" Well, that dream came true last year when they released Flutter 2 and web support.
So what happened when I decided to create this blog? In my head it was never a debate on the front-end technology/framework selection: Flutter it is. The initial thought was: a Flutter web application calling a few back-end APIs (Application Programming Interfaces) that would be responsible for interacting with a database. All of that in the cloud using as cheap as possible services. Sound and simple! (I thought)... but, the devil is always in the details:
- I work solo here, so building those components myself from scratch would take some time and I don´t know if you remember but my hours to work on this blog are limited (I talked about this in the Framing the Problem post)
- As soon as I decided to use Amazon Web Services - (AWS) as the cloud provider for this blog (more on that on future post) and I started thinking about how to host my Flutter web app I noticed that the viable way to do it is using the AWS S3 service. Even Amplify don´t support web hosting (yet) which means spending more of my time to deliver the product
- Search Engine Optimization (SEO) and Flutter don´t go well by default as Flutter uses HTML Canvas Graphics to render the website (not generating the HTML tags that are used in SEO), which means more time invested to make it work
- I do like Flutter, but remember the main advantage of using it for development is the ability to ship applications to Android, iOS and web simultaneously from one codebase. So, let´s do a quick sanity check here, open your phone and let me know how many blog apps you have installed. I did the same exercise and I have exactly: 0! That is correct 0 apps! I read blogs in my phone or pc using the browser and my hypothesis is that you probably do the same
- I never intended to release this blog as a mobile app so... what is the point of using Flutter again?
The initial solution itself was simple and I can probably justify this solution with the Motivation card "Learn Something New" (check out Hello World post if you don´t remember what I´m talking about here) but what about the "Be a Lazy Programmer" one? Remember the main focus here should be writing blog posts and creating content! Which brings us to COD.
In his book The Principles of Product Development Flow, the author Donald Reinertsen describes Cost of Delay (COD) as being the "one thing" to quantify.
"We need Cost of Delay to evaluate the cost of queues, the value of excess capacity, the benefit of smaller batch sizes and the value of variability reduction. Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mind-set of a development organization"
Excerpt from Wikipedia (so it must be true! [3])
Now that we understand COD, going back to brainstorming about the blog, can we ship it faster (reducing the cost of delay) and simplify things at the same time? Is there something already built that will accelerate the delivery? The answer is Yes! There are many ready-to-ship open source tools that can help put a simple blog together such as: WordPress, Ghost or Strapi that have many different hosting options (hum... should I revisit the AWS decision as well?).
And that is how laddies and gentleman that a decision was made to pivot completely what I have initially imagined as technology stack for this blog. Pivoting is good, changing your mind on something is also good. In this specific case, it is a no brainier as it makes sense to pivot. I know that some decisions are hard to leave (miss you Flutter 💔️), but at the end, you can put your head in the pillow and sleep well because KISS and COD tied together!
I already spoiled previously that I decided to go with WordPress here but there are more details to be explored on that decision that will definitely go into another post.
See you there!