Quite a while ago now, Lars spoke about writing the scaffolding of your projects as a first step. We've covered all sorts of things like how to lay out your codebase and recently about motivation for projects in the first place.

And all this is good. You've decided you want to write something awesome, you have a design which you think will lead to an amazing program which will wow the world. But it's going to take you about six months of engineering before you can get to the result you've designed for. That's an awfully long time before you know if you're doing the right thing.

Lars spoke of TDD (test driven development) in his scaffolding article and that's an excellent way of ensuring that everything you write is validated. Sadly it does nothing to guarantee that everything you write is useful or desirable in implementing your final solution. There are a number of ways of bridging this gap and today I'm going to talk about one of them.

The "Minimal Viable Product" is a process whereby you develop the least you possibly can to give yourself an edge or unique selling point; and the same thing can be applied to software engineering. You can shorten the feedback loop, reduce the chance of developing something undesirable, and get to a program which is of use to you as soon as possible; if you focus your early development effort on a minimal viable project.

You should take time, after you've done your high level architecture and design discussions to gather by a whiteboard and come up with the absolute bare minimum of your feature set which you could implement and produce something which can actually be used for a real-world use-case.

Then, after you've implemented your MVP you've likely had to amend your design documentation a good amount (possibly even fundamentally). Fortunately for you, you come out of the process with something which does something useful (and thus can be effectively evaluated) and every change you make to your design as a result has a grounding in the reality of implementation.

Your MVP could be thought of as a prototype. Indeed some developers prefer, at this point, to throw away the MVP and reimplement it again with the insights gained during the implementaiton. What is important about an MVP though, is that once you've been around the prototype loop a few times, you keep the MVP code and evolve your final project out of that codebase. This critical difference between an MVP and a pure prototype allows you to bring online continuous testing and continuous integration and deployment if appropriate, the moment you have your MVP ready (or even before). And remember, if it's not tested, it doesn't work.

Your homework this week is to look at some of the designs or READMEs you've written of late, and think about what an MVP might be which could lead you to greater insights into the problem, or even toward your final solution.