Minimum Viable Programming

My background is in software development, not marketing, not sales, not real estate … its software development. Over the years I’ve been a full time employee, consultant and business owner and entrepreneur.  While the businesses I’ve started are not making gobs of cash like Yelp or Facebook, they definitely make my life a lot easier by generating recurring revenue streams. These types of businesses are usually referred to as lifestyle businesses. I’d agree that my businesses currently fall into that category, to a point. That point being that one day I’d like for one or two of my companies to get large and eventually employ many people and such. When a business gets to that stage, its exonerated from the lifestyle business status. But given the stage I’m at now, I fall into the lifestyle business category and I’m ok with that.

Getting these businesses off the ground to generate revenue is not an easy task though … its a fly wheel / hamster wheel type of paradox (a Hamster Wheel business requires constant work to keep moving – such as consulting, but a Flywheel can be left relatively unattended – a business which operates on memberships or consumers purchasing product ). A flywheel takes much longer to get going, but you can walk away from it for a small amount of time and it will continue to run. While a hamster wheel stops almost immediately as soon as you get off. Building a business that constantly generates revenue from a software perspective takes time. The problem is, time is a developers main resource. Without it, we cant make money. So we have to use it wisely. Blow too much of it on nonsense and you’ll have no money. Spend all of it on consulting, then you’ll have a lot, but as soon as you stop, the income stops. My goal was to build a business that acted as a fly wheel. To do that, I had to really refocus my time as a developer when building products and shipping them.

I often get asked “Donn, how do you get products out the door so fast? How do you test the market? I’m having a hard time getting my product out the door.” These questions are normally from other software developers I’ve met in the country throughout my various consulting and speaking engagements. The answer I give them is simple – stop being a perfectionist and focus minimum viable programming to get the job done.

Minimum Viable Programming (for developers)

When developing a product, you want to get it out the door as fast as you can so you can validate your idea and make money. Most entrepreneurs are familiar with the term “MVP” or Minimum Viable Product. The formal description given by the Wikipedia entry here says it better than I can:

A Minimum Viable Product has just those features that allow the product to be deployed, and no more.

Pretty simple right? For everyone else, sure. For a developer, NOPE. Let me explain.

Screw Patterns and Practices (kind of…)

As developers we’re told to follow patterns and practices (hell, I’ve been preachy about this topic in my blog many times) and to not shortcut development items as it will later come around to bite you in the ass later on. Lets assume you’re building a 5 page web application that can bank 10 dollars per user on a recurring monthly basis. A typical decent developer will look at this and think “well I’m going to need a repository layer, a service layer, maybe some queueing to handle scale, a visitor pattern here and some fancy code to handle the user registration process.” This leads to more design decisions/etc. Before you know it you’ve spent 3 days on a design for the CODE … THE CODE … before even touching the user interface or user experience.

The problem is… CODE DOES NOT MATTER.

Not one user that I’ve dealt with (unless they were a developer) has asked me what the system was written in. They didnt care. They only cared that it solved their problem and they could use the app. They didnt care that the code was logically layered into 5 layers with a 3 tier architecture with a queueing middleware. They didnt care and they wont care.

So there is PROBLEM #1. You (the developer) are already over thinking it.  Stop thinking so hard. Just do the minimum in order to get the product out the door.

I’m not saying that you should copy and past connection strings all over the application, but stand back and ask yourself this:

If I spend 10 days on this and no one uses it, how pissed am I going to be?

Most likely answer: Very pissed.

If I spend 2 days and HACK it together (whilst not pretty, it works to the end user and the product executes as it should) and no one uses it, how pissed am I going to be?

Much less pissed than the prior.

All I’m trying to say is this … follow a minimum viable programming model to get the app out the door. Sometimes its makes sense to put common things into a class. Sometimes it makes sense to abstract something because it needs to be changed for unit testing/etc. Sometimes it doesnt. When it DOES NOT, call YAGNI (http://en.wikipedia.org/wiki/You_ain’t_gonna_need_it) on it.

Minimum Viable Programming is about performing the minimum amount of programming that you need to do to get the product out the door. Because getting it ready for use is only half the battle. You still need to market the app, provide support and sell it.  Give yourself more of a chance than others, do only what you need to get it done. Once its done and shipped, if it makes money you can then come back and do it right at that point because at that point you are already generating revenue and you’ve proven your model. At that point, iterate, change some code, and ship. Iterate, iterate, iterate. Always improve the code base at that point. But when you’re starting out, forget that nonsense. As many people have said: “It it don’t make money, it don’t make sense”.  Be as lean as possible in the beginning … get your product out the door at all costs, even code quality.