DEV Community

The Struggling Dev
The Struggling Dev

Posted on • Edited on

1

MVP as an Excuse for Bad Code?

Introduction

I've recently had a discussion about Minimum Valuable Products (MVPs) and what exactly they are. Actually it was more buzzword name-dropping. The interesting part was, the context in which it came up: hardware development.

In this case, the MVP was explained to me as an "ugly gray box". A thing you put together to see if an idea works. It's just made up of some cobbled up components that are laying around, some duct tape and an idea.

Ever the critical developer, this struck a nerve. To me this sounded more like a prototype than an MVP. Don't get me wrong I don't want to say it's wrong to call what they do an MVP. Hardware development is a very different beast than software development - I assume, and I'm not even sure whether this is a widely adopted nomenclature. It just made me think of the "dangers" when you interchange these two things in software development. And for software developers who've never heard of an MVP, this sounds like a free ticket to hack something together.

Which, at least in my opinion, it's not. So let me try to define different approaches to software development. This is my interpretation, if you disagree let me know - I'd appreciate it.

Proof of Concept (PoC) or Exploratory Programming

What you do when you hack something together after you've identified the critical parts of the thing you want to implement. E.g., you have to implement a feature in an existing app, you need to use some framework tool you've never used, you have no idea whether you're approach will work, ... . You know, you'll need to properly integrate your feature, get the values from your data store, pass them properly to your feature, validate, ... But you kick that all to the curb, misappropriate the first and easiest to call button in your app, pass some constant values in, ignore all code style rules and just figure out if there's a chance this will work.

This is no product, just loose parts.

Prototype

You have an idea for a product, but you're not sure there's a market for it. You implement all you need to figure this out as quickly as possible. Whether there's a market or not, you usually scrap the prototype. If you have a market, you start working on an MVP. If not, you start over with your next idea - or in lack of one, go to the next pub.

This is also no product, but it has the potential to become one.

Minimum Viable Product

Now we finally have a product, it's right there in the name. We know we have a market. We now have a software product, that we will need to maintain. So this is the point where we stop programming and start developing. We concentrate on the most important functional requirements and leave the nice to haves out. We might also postpone some non-functional requirements as long as they aren't relevant to our architecture decision. While PoCs and prototyping are acceptable reasons to program quick and dirty and don't care about architecture, this stops when we start implementing an MVP.

Sometimes people ask "What's the difference between a programmer and a software developer?" I recently heard a definition, I kinda like. The difference is time. When you're developing software, you take into account that your software needs to grow (needs to develop) and change because it will be around for many years. A small program you just use once, or that never changes, doesn't need to adhere to the same standards of maintainability. In the end it's a mind set.

Closing the circle

One reason I can see why it's less "dangerous" to call the ugly gray box an MVP, is that creating hardware and software are so vastly different things. When you create a hardware product you inherently know that you have to start from scratch once you're finished, you can't copy hardware as you can software. Your ugly gray box consists of off the shelve parts and your battery is duct-taped to the box because it's too expensive to commission a special Möbius strip-shaped battery so it fits into your fancy designer box. Your ugly gray box also won't get the approval stamp from any authority.

I'm curious to hear other points of view, so drop me a comment if you like.

Thanks for reading and keep on struggling.

👋 One new thing before you go

Tired of getting nickel-and-dimed on your software career? 😒

We have created a membership program that helps cap your costs so you can build and experiment for less. And we currently have early-bird pricing which makes it an even better value! 🐥

Just one of many great perks of being part of the network ❤️

Top comments (0)

Heroku

Build apps, not infrastructure.

Dealing with servers, hardware, and infrastructure can take up your valuable time. Discover the benefits of Heroku, the PaaS of choice for developers since 2007.

Visit Site

👋 Kindness is contagious

Explore a sea of insights with this enlightening post, highly esteemed within the nurturing DEV Community. Coders of all stripes are invited to participate and contribute to our shared knowledge.

Expressing gratitude with a simple "thank you" can make a big impact. Leave your thanks in the comments!

On DEV, exchanging ideas smooths our way and strengthens our community bonds. Found this useful? A quick note of thanks to the author can mean a lot.

Okay