Developing a side project made me really embrace the MVP mindset

I never thought developing a personal side project would make me enthusiastic about MVPs… It’s not easy making something simple! In our complex software engineering landscape, I feel we have a tendency to look for sophisticated, state-of-the-art solutions in answer to simple problems.

I started developing a side-project with a double goal. On one hand, to actually tackle one of my recurring problems and automate the solution, and on the other hand, to find again the joy of concentrating on algorithms and problem solving instead of writing yet another CRUD and REST API.

However, after the first few coding sessions, I realized I went straight to the complicated, almost over-engineered solution. I found myself again coding operations on a database, setting said database, writing an API to trigger my app logic thanks to http calls… Nothing crazy here, except that I was working on a project for my own pleasure, and found it more difficult than expected to keep things simple and iterative, although I finally had the opportunity to.

I realized soon enough and made big changes to my plans, switching from a perfect but complex solution, to a perfectly fine MVP.

What is a MVP

A MVP, for “Minimum viable product”, is a version of an application that is viable, meaning it does work, but contains the bare minimum in terms of functionalities. It focuses on core functionalities and normal situations, leaving finetuning, edge-cases, optimizations… for later. Maybe.

It’s not to be mixed up with a POC, for “Proof of concept”, that has a different purpose. The goal of a POC is to prove that something is achievable and demonstrate it to stakeholders, generally to get a buy in on an innovative project. It’s usually not meant to be reused for further developments, contrary to a MVP which is a base for iterative developments.

Other acronyms that suit the MVP mindset:

• KISS, for “Keep it simple, stupid!”, is a design principle that encourages engineers to design simple solutions (duh). Simplicity of the code and solution become a leading principle, even a target. Nothing superficial is allowed in the solution, making it easier to maintain and to understand.
• YAGNI, for “You ain’t gonna need it”, is another principle stating that developers should only code what’s needed now (duh again). Unnecessary code and functionalities shouldn’t exist in the project. I have a really good example of non-YAGNI development that I witnessed a few years ago: creating an interface in Java that is implemented by a single class, because you think there might be other classes sharing some of the properties in the future.

Why it’s difficult to keep it simple and improve over iterations

Even though a lot of development teams claim to be working in Agility, I’ve rarely really felt so. The main difficulty I see it that applications are so complex, it’s difficult to add new functionalities, even in their simplest state, without having to operate big changes on the code base.

The pressure of the stakeholders, the difficulty to show value with “half done” functionalities, also makes it less easy than it should. With continuous deployment, you cannot merge functionalities that are not finished (or you’d have to use tags in your code to hide the functionality until it’s ready, which adds some work load).

At developer’s level, I think we tend to repeat the approved recipes, like the SQL-database-CRUD-layer-service-layer-REST-API one that is applied in many development projects. I’m not saying it’s not valid, I just feel like this became automatic for many of us, developers, making it difficult to imagine other workflows and architectures.

Personally, I’m also aware I have a hard time making things “for nothing”, and trying to figure out the right architecture upfront seems like a secure way to do things right directly. That’s specifically what I’m trying to fight right now, and my personal side project is helping me big time!

A real life example of downgrading from a picture-perfect over-engineered solution to a minimalist, iterative one

My use case is an app that will generate the weekly meal list for us (my partner and I), so we don’t have to blank out regularly in front of the grocery list, or to think of what we want to eat that week.

I have great plans for that app. I’m instinctively so not-MVP-minded that I was already thinking about promoting the app and imagining ways to make money out of it before I laid a single line of code. They say the first step is acknowledgement, so I guess I’m on the right track…

Technically speaking, at first, I spent quite some time thinking of a good way to design the database (I like that part, it gives me clarity over the development to come). Then I developed an app in Kotlin*, creating all my layers, writing CRUD, models, services, up to the REST API… (good for me, I wrote of my models but only one end-to-end workflow).

(*yes, I changed my mind about nodejs, been there, done that, went straight back to the jvm)

After some time pushing the next step of the project to later, I realized maybe I should focus on a simpler first version. I changed my database schema, which in turn would simplify all other layers (services, models…). I also pushed some functionalities to later. And maybe I didn’t even need a front-end to start with.

But it still wasn’t it. I could make it even simpler.

I had an ah-ah! moment while hanging my laundry (made me think of that talk about developers’ productivity). Suddenly, it appeared clearly: I didn’t need an API, I didn’t even need a database. Of course, a database would make it more optimized and normalized. Of course, an interface to input things in the database would make it easier to use. But none of those functionalities were mandatory.

That’s when I started all over again.

How to approach a project with the MVP mindset

First, I went back to the most important thing: the users’ needs. For once, I can use my users as much as I want, so better make use of them. Right now, our needs are to generate a weekly menu and the associated grocery list, taking into account the category of the recipes (this is to avoid ending up with a fast food week and whole meals twice a day).

Then, I tried to forget everything I know about software engineering, except the very basics. What’s the easiest way to store recipes? Probably a text file. I just need it a bit structured to be able to decode it in my program. What’s the easiest format for a human, that is also highly parsable? That would be yaml, right? JSON would be the best choice for switching to a REST API later on, but that’s not how we want to think anymore!

Another point is questioning the reason for using this or that technology or workflow. Why am I using a REST API? So a user can trigger the creation of the meal list. Yeah, but then I need to expose my API, make it accessible for chosen users. Is this really the easiest way to trigger the weekly menu generation? That’s while questioning this that I realized I could as well create a cron job, given the repeatability and regularity of the need. This way, we don’t even have to think about it at all.

Simplifying the technical aspect made me realize what wouldn’t work in my project

While focusing less on technical, and more on functional aspects, I was able to spot some constraints I had not taken into account in the algorithm I intended to implement. Thinking about technical details, or future features, distracted me from the core of the application itself.

Other than the user functionalities, it also allows me to directly notice potential pit falls and improvement priorities. By not optimizing anything, including not applying the DRY (for “Don’t repeat yourself”) principle in the first place, I can quickly see there are risks of duplicating some logic or using the wrong keys in different part of the code.

Going for a MVP made the project exciting again

I got a little bored by software engineering because of the amount of REST APIs, CRUD operations, gateways… we get to develop in classic software architectures. It was one of my goals with this side project: I wanted to try new things, choose my setup, get some fresh air…

This new approach gives me the motivation to go on with the project, as I finally get to spend more time on the logic of the app and less on the repetitive tasks. I will get to do things in a different way, and as long as I accept that they might be temporary, I’ll get more opportunities to learn than by repeating the things I’ve already done tens or hundreds of times.

Starting small allows to reach milestones more often, see faster results, and lower the risk of getting discouraged by the project. It feels less overwhelming to work on smaller scopes and to keep on learning and trying new, but simple, things.

Other reads

Still procrastinating on your project? You need an MVP. On how Michelle finally got sh*t done on her personal projects when she discovered the concept of MVP, and embracing a start-up mindset for side projects.

A plan for planning your first side project. Quoting: “One of the first things that may cause your project to go into a pile of abandoned GitHub repos, is if you get an idea and then you don’t limit the scope of that idea to an MVP.” Angelika also explains the process and lists useful questions to define your MVP.

Why you won’t finish your side project. Junaid lists the common reason people don’t complete their side projects, as “over-engineering”.