The first time anyone sees the code of an MVP app, its like seeing shit that you cannot un-see.
One will generally have questions that sound something like the following…
Why do we have only one 50k line long controller? (This is not a joke, I’ve seen this in a rails app)
WTF is this?
Why do we have pages and pages of commented out code?
And the always classic, our test coverage is what?!?!
There are a lot of studios good at building Minimal Viable Products or MVPs, there are tons of books out there on building an MVP.
I am convinced the vast majority of coding schools revolve around teaching a kid to build an MVP without teaching them anything else about coding, like…I dunno…coding?
There is an entire industry around MVP-ing, I am pretty sure there is also an MVP on MVPs, so the MVPs can MVP their fucking MVPs.
Therefore, the hard bit is not building an MVP, everyone knows how to MVP.
Don’t do stupid shit
The hard shit is growing an MVP. The hardest bit of that shit is to grow an MVP into code and infrastructure that can support the 99% (Massively Marketable Product or MMP), is STILL knowing what NOT to build.
Via negativa, if you don’t do stupid shit, then everything that you do, logically should be either good shit or at the very least, non stupid shit.
The really simple development process
We have about 4 steps in our product development process. They can broadly be defined as categorisation, prioritisation, execution and testing/deployment.
Step 1: Categorisation
We separate all work to be done to the code, regardless of client or server applications into two camps, SUPPORT issues which are bugs found in production, and UPGRADE issues, which are essentially the things that the company would like amended or implemented.
SUPPORT issues are easy, they all need to be done, it’s just separating them by severity and handing the work out. Some things need to be done now now now, and some can be queued up for the usual deployment.
The challenge is with the UPGRADES, everyone from marketing, to product management, to customer engagement to Tom, Dick and Harry has an opinion on what should be next added into the HelloGold application.
Step 2: Prioritisation
Wykeen and the CEO of the company sit down every now and then, and filter through the noise that is our upgrades Trello board.
I guess this is where experience and a clear strategic vision of the business is required, a 20 year old greenhorn who dropped out of college is most definitely going to suck at this part.
Robin and Wykeen then proceed to chuck the garbage requests out, and choose to do UPGRADES that value add to the company or product in an exponential manner.
Step 3: Execution
Once that is done, the engineers (CTO included, hey we’re still a startup) get assigned the work and we get cracking.
Nowadays we try to enforce a soft TDD, you can either write the test before you write the code or after, but you should have some form of automated testing for whatever it is that you are implementing.
We usually do not pass pull requests that have zero testing.
Step 4: Testing and Deployment
We essentially have 4 environments, the dev’s local, a remote development environment, a staging environment and then a production environment.
The product managers test on staging and the only difference between staging and production is play money/gold vs real money/gold.
Once the product managers are comfortable with what is developed, we run a deployment cycle and release code/app(s) into the wild.
I more likely than not over simplified our process, but the 4 steps represent the gist of how we do what we do. There are no magic bullets, its just us here grinding away at code and pushing it into production.
So there you go, our bare-ass basic bitch development process, there is no bullshit to it, just engineers surviving on caffeine and cigarettes, banging out code and writing their own tests.
Hit me up if you need help implementing this STRATEGY in your startup, I’ll kick your ass for you.
