This article is not about security. It’s not about established products that are circulating the market. It’s about getting started with software development from the POV of a developer that loves to over-engineer everything.

If you’ve read anything that I’ve written previously, you’ll know that I subscribe to the MVP (Minimum Viable Product) mindset.

When most developers hear MVP, they think about fast turnaround and low-quality code. What most don’t understand is that you can define MVP to fit your mindset.

What’s the Problem?

The problem is that some developers feel like they need the requirements presented to them in full in order to create an application. This type of mindset is difficult to break. They might have worked for a company that spoon-fed the requirements to them. They might have worked for a company that was obsessed with the waterfall approach. Whatever the case may be, these developers do not want to build MVP applications.

The Solution

It’s just a simple mindset change. You don’t have to build low quality code. You don’t have to have little-to-no requirements. You can have it all. The solution is to reduce the number of features you make.

The following is the approach to MVP that I frequently take when I want the project to be as error-free as possible. After-all, MVP’s have a negative stigma attached to them: full of bugs.

• Start off with mapping the application that you want to build. I normally use a tool like Miro and create a brain-map. The brain map loosely lists features that I want to build. If you’re working for a client, this is the time to jot their ideas down.
• Categorize the features into phases. Which are the absolute must have features? Can any of those features be moved to phase 2 or later?
• Once the features are sufficiently narrowed down, it’s time to start creating Use Cases and/or Feature Design Documents. Create as much documentation as you feel is necessary. Make sure that each use case represents one action.
• Agile away. Create tasks and organize your backlog. Group the tasks into sprints.
• Once you start writing code, focus on having it as loosely coupled as possible. One feature at a time. Take your time and make each feature perfect.
• Rinse and repeat. Once you’ve completed the features agreed upon, it’s time to go to market. This is not the time to add additional features.
• Once you’ve received some input from the users, it’s time to prioritize phase 2 and start working again.

The idea is to get you to write code, but to do it in a managed setting. Too little documentation and you’ll feel overwhelmed. Too many features and you’ll also feel overwhelmed. When you have just the right amount of documentation paired with the right amount of features, your application will be successful. Eventually you will have all the features that you wanted but they’ll be created one step at a time. Your chance of a successful application will be much higher if you take this approach.

If you dwell too long on requirements, you’ll never begin writing any code, and your application will always just stay as an idea. If you’re the type of developer that must have everything perfect, I think this is a fair compromise you can make with yourself. In the end, the answer can always be MVP Software Development.