I’m a big fan of open source software, mostly because I’m a big fan of software in general and I like to look under the hood and see how things are done.
Open source takes the guesswork and decompiler interpretation weirdness out of the equation which ends up saving everyone time. Also, there’s the obvious benefit of having other people work on (and improve) your code.
If you’ve been in the software development space a bit then you will have come across the term Minimum Viable Product (MVP). Defined as the smallest feasible implementation of something that does what it sets out to do. MVP launches have been responsible for no-bells-and-whistles releases since the dawn of software.
Traditionally the Software Development Life Cycle (SDLC) looks something like this:
Image from Husson University.
- Planning
- Analysis
- Design
- Implementation
- Testing & Integration
- Maintenance
This model has worked great for many years however, I often find myself injecting and performing an undocumented step. Turns out this step would be the most fun of them all.
I’ve come up with the term Minimum Viable Public Product (MVPP) to describe it. The smallest viable version of the software that can be publicly released.
No personal use-case specific features, no settings or third-party integrations that would only appeal to a small subset of people, nothing your mom wouldn’t want out of the box.
I’ve found defining an MVPP early on in the SDLC to be incredibly useful, especially when dealing with scope creep when all those shiny nice-to-haves come knocking. Sorry can’t deal with you now, I need to get this code on Github first.
Surprisingly, the MVPP has also helped me ship (i.e., publish to Github) more projects than I usually would.
It helps deal with overthinking and gives you a clear goal which will be good enough for other people to see, which can be a scary thought otherwise.
My updated Software Development Life Cycle looks like this:
*I really was trying to write neatly.
- Planning
- Analysis
- Design
- Implementation
- Testing & Integration
- Release minimum viable public product
- Maintenance
I find that after I’ve released the MVPP is a good time to start working on my use case specific features and third-party integrations, which generally leads to a more repeatable development process.
You’re going to be doing these steps anyway, now your Github thanks you sooner (and more often) while you release cleaner code with less extra baggage.
Let me know what you’ve been working on and releasing publicly over on Twitter if you want, Github stars all around.
Thanks for stopping by.