Minimum viable feature

We have all heard about the Minimum viable product, and it is a great thing to strive for, if you are doing software development (or design). What in hell are the minimum viable features then? As the MVP(Minimum viable product) is defined as a product has only the bare minimum of features that allow it to be deployed, the same can be said for the features that the project is composed of. The guys from Basecamp once said something like this: Rather build half of a product, than a half-assed product.

While creating software, we often get carried away by shiny features we can add to the project, features that we may not need at the moment, or at all. Premature architecture optimisation is one of them, adding visual junk to html is another. Of course we all love shiny, scrolly, bumpy applications, but if you are creating a let’s say business application, you probably don’t need

that super fancy ajax loading widget that refreshes every 5 seconds. Or to have all of your 27 rows that get rendered in a select field properly cached 7 times in memcached, or redis. It just doesn’t matter at the moment.

What matters is that the product works according to the user story you have received. Same as the MVP on a bigger scale, when you get a new user story, ask yourself, what is the minimum possible set of code that I need to push this feature out. Thinking like this, you will create features in less time, which leaves plenty of time to write tests for your code (which I know all of you are already doing), and more time to spot out the flaws in your code, the user story, the UX, whatever.

Before you run out and create something barely usable, while finger pointing at me, please consider some base standards on how your application, and the features should look like. You can’t just put 5 inputs on a form, stick it on the page, write “Submit” on the submit button, and be done with it. You must make it look visually pleasing. It should also work fast enough that the end user can use it in a normal way, but not faster. While having super fast applications, where everything is cached, and vertically and horizontally scalable at the blink of an eye, if you are serving maximum of 42 users from your local government office, you could say you threw valuable time into something that you really don’t need.

I’ve comprised a list of questions I ask myself, which help in trimming down each feature to bare bones, while maximizing productivity:

1. who will be using this? (how many people, what profile)
2. what will be the impact of the feature to the whole system? (maybe some collision)
3. can this process be reduced even more? (optimize work flow)
4. should this feature be split in two or more features? (maybe it’s too elaborate)

Guiding myself with these, I’ve successfully produced feature after feature, all small and isolated, working their own things in harmony with the rest of the system. Now, to be honest, I’ve also written some bad code in the past, features that had nooks and crannies that I just had to put there. Or the story owner wanted them in, but that is a different story, about a really powerful and liberating word, NO.

Try to be concise, try to add only the things the feature needs to work. And hold yourself up to the project standard. If your project doesn’t have a standard, go write one. I could bet that no one will be mad at you if you create something good for the project. When creating the standard, remember why you are creating it, and keep it short and concise, with the minimum information needed to convey the information.