What is a MVP and how to avoid overengineering

What is a MVP?

I can already hear you shouting at me about the fact that you came here to learn more about software engineering and here we are, talking about annoying stuff like marketing, product, time to market and so many other boring things.

As we do not want our good friends from other departments to hate on us, we must surely define what we stated above as a joke. Nothing of what you do is boring or annoying, it's just that we are all pretty much lazy fuckers.

But what one can discover through seniority and years of expertise is that any part of the company is important to the life of the product and that means that sometimes, we software engineers should better evaluate our importance in the lifespan of the product.

"But I'm an engineer, I'm the one giving life to the product" - said any software engineer reading this article.

And yes, you are one of the parents of this kid, but as it's 2022 you might want to realize that family is whoever takes care of you, and by you I mean the product.

Balance is of the essence and all departments are important to the life of the product. A beautiful, perfectly engineered product that does not undergo marketing strategies might never see the light of day. So, philosophically one might argue, does that beautiful and perfect product even exist?

So, with the first part of this rant being done, we can finally start our blog post.

A Minimum Viable Product is a choice that companies should make to enable early users to adopt the product, which is the most important metric maker, so that features can change and adapt depending on the users' feedback. In its own way, this can also be considered an agile methodology that enables teams that work on the product to be fast, efficient and lean.

A Minimum Viable Product, MVP from here on, is a development approach that can save you time, money and effort. Pretty neat.

Now, how would you go about making a MVP?

The answer lies in your core knowledge. Whether you are alone, building your own SaaS, or part of a company with engineering managers, principal architects and VPs of anything that exists, the choice should lie between what is solid, consistent and safe and what is known, perfected and fast.

That's a lot of words so you might be wondering: "the fuck did he say?"

What I said relates to the fact that as software engineers we are always tinkering with new toys, languages, libraries, dependencies and all the latest jibber jabber that makes our brains go wild.

Is it fun? Yes.

Is it a good choice for MVPs and SaaS? Usually no.

So, in the spirit of our engineering methods and after quite a few written words, let's have a list so that we don't spoil our brains too much, reading things that are not if, else, while, for, function.

1. Solid are tools that enable you to do your job without too much randomness
2. Consistent are tools that will not surprise you in production
3. Safe are tools that allow you to avoid errors
4. Known are tools that you've been using for years
5. Perfected are tools that a lot of people have been using for years
6. Fast are tools that respect all of the above

The goal of a MVP is to allow you and your team to respect the product time to market, validate what you engineered and move forward to the betterment of the product itself.

As Software Engineers, it is our job to build the best products but sometimes it becomes necessary to release before readiness and this is usually due to the fact that the company is trying to achieve marketing goals, better funding and ideally, reach out to more audience with new and shiny features.

When that is the case, we should be very wary of our traits because most of the times we software engineers tend to do something that is definitely not product oriented, and that something is overengineering.

What is overengineering?

Overengineering can be considered a bad practice that was born from good spirit. At least that's what I like to think.

Overengineering can be summarized in shooting at a fly with a cannon.

With over excessive attentiveness and too many sprinkles of perfectionism, we tend to value our ego's needs over our client's needs, the company's budget and the actual leaks of the systems (libraries, frameworks and languages) that we are using, because we should remember new does not always mean safe to use in production.

As software engineers we surely have a lot of fun searching for the best algorithmic solutions, dealing with complexity and pushing our systems to perfection, inch by inch, but that's not something that all the companies can do because sometimes we have deadlines that should be respected.

To avoid entering the loop of perfectionism, one should understand when, why and how to allow oneself to get lost in the act of perfectionism.

The search for perfection is as old as humans and a battle that will continue and will make us strive ever forward, so it surely is a good battle, but it's not always the case to be there!

How can I avoid overengineering and become a better developer?

Avoiding overengineering is simple but never easy because as we stated a little above, it is in our nature as humans and especially as software engineers to look for better and more innovative solutions.

From my perspective, the solution lies in timing and choices and is everchanging and always dependent on the product, the team and the results that the company as whole wants to achieve.

To avoid overengineering start to actually listen to the rest of the team and see where some features are needed, some others need to be perfected and where there's room for improvement.

The goodbye

I hope you found this article useful and to your liking and if you have any requests, drop a message on one of my social media accounts or open an issue/start a discussion on github, on this repository!