MVP in Personal Projects

One of the hardest parts of doing a personal project: MVP

I have a GRAND vision of what this will be. I want to BUILD IT ALL NOW!!!

But I know that you can't eat an elephant at once.

MVP= Discipline.

It focuses you on what needs to be done at the moment and not what will be in two weeks, two months, or two years. I may not be shipping to a customer but I'm shipping to myself. And I'm being disciplined to ship small increments to myself.

MVP leads to cleaner coding.

Instead of writing code to handle 5 similar scenarios, handle one first. When you go to handle the second one, you can refactor and keep everything following the Single Responsibility principle in SOLID principles.

I use Azure DevOps for my project planning. IMO, it's the best tool for planning software development. By planning my work, I can ensure I'm staying true to the MVP ethos.

FAQs

1. What is the concept of MVP in the context of personal projects?

Often, MVP is just about getting something working and proving the concept. If you want to handle multiple similar scenarios, build the code to handle one of them first. Then go back and see what you need to change to do the second scenario. Anything that doesn't change becomes part of a base class. The rest goes into a sub-class.

Complete the second scenario before moving on to the third. And then the fourth. And fifth.

Each handled scenario is an increment you're delivering to yourself.

2. How does practicing MVP help in maintaining discipline during project development?

By forcing yourself to break the project up into small pieces, you force yourself to build and deliver small increments rather than trying to tackle monster-sized problems. The small bites approach gives more frequent rewards which feeds the desire to continue with the project and the resulting cleaner code reinforces the positive behavior.

3. How does using Azure DevOps contribute to staying true to the MVP ethos in project planning?

Azure DevOps makes managing work items very easy. Items can be cloned and split with ease. This process is analogous to refactoring code. As your understanding grows, you can add new items, split items, or remove items. You can introduce more granularity into your planning. This granularity should reflect in the code being written and "delivered".