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 consist of off the shelve parts and your battery is duct-taped to the box because it's to 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 the hear other points of view, so drop me a comment if you like.

Thanks for reading and keep on struggling.