There is a saying. I’m not sure where it comes from. I’m not even sure if I made it up entirely. But I find it entirely appropriate when developing software.

The first solution is usually not the best solution. But it’s better than no solution at all.

Programming is all about solving problems. It’s about breaking difficult things into smaller things you already know how to do. Most of the time though it doesn’t really matter how good your solution is. Especially if it gets the job done.

A similar quote, attributed to Voltare, that’s probably a bit more popular goes something like this:

Best is the enemy of Good.

Obviously you could go to town with this idea and create some of the least maintainable software that man has ever seen.

Maximum Viable Product

If best is the enemy of good then Minimum Viable Product (MVP) is the enemy of getting anything half decent done at all. I don’t have a problem with MVP in theory. The idea of choosing to ship the smallest and simplest solution first and then build on it is a logical one. Developers get to see their software out in the real world quicker, users get something to play around with earlier, and the company’s bottom line gets a bit of a boost.

It’s very easy to take MVP too far though. Usually this is based on a mis-interpretation of exactly what the word ‘viable’ means.

The Tale of The Minimal Commute

A poor lonely user wants to get to work. He finds himself walking for hours a day and wishes there was a simpler solution. Deciding to commission some software engineers to solve his problem he draws up a list of requirements:

• I need a wheeled vehicle
• I should be able to get to work with it.

Seeing the requirements the software engineers flesh them out to a full design specification:

• The deliverable should be a vehicle
• The deliverable should have 4 wheels
• The deliverable should have an engine
• The deliverable should be capable of travelling 17.6 miles 5 days in a row without refuelling

All going well so far. It looks like our user is going to get a nice small car to drive to work in. Then MVP hits.

“Do we really need 4 wheels in the first version?” asks the first developer. “Could we not get away with something simpler, like 2 wheels” he proposes. After much discussion the team eventually decides that 2 wheels sounds like a good solution for the first version.

“The engine sounds complex” suggests a second developer. “I’m worried about how long that will take. Could we not get away without an engine in the first version and add one in later?”. Again the proposition is discussed and it is decided maybe the user could just push the vehicle himself initially.

The discussion continues over several days until it is decided that the user won’t push the car himself, but rather he will rely on some dogs to drag it. And also due to the technical complexity of balancing something on two wheels they will use two skis instead.

Time passes. Eventually the user is presented with the finished product. It’s not quite what he had in mind.

“It’s not quite got all the features of the final version” says the lead developer, patting the husky-sled earnestly. “We did manage to get some good features in though, like this bespoke cup-holder” he continues. Showing off the intricately carved wooden device as he does so.

“It’s not quite what I was looking for” the user replies. “It is a nice cup holder though. And I suppose I could get a new job in Svalbard. Then I would travel to work over snow and ice each day and this would work great”.

“I knew you’d like it” the development manager smiles. “Just wait until you see version 2.0”.