There isn’t perhaps a more covert and enduring cold war confronting two opposing ideologies in the engineering world more than the one between those who embrace an incremental approach versus those who intend to get it “right the first time”.
And with this, I strictly mean it from a deployment strategy side. In other words, the criterion to define when something can be released to an audience, be it a piece of software, a satellite, a hairdryer, or even a book. And here it is important to state the obvious: all engineering approaches are iterative and incremental at their core. No one does it in a linear, unidirectional way; we all go back to previous steps to make changes, rerun part of the work, modify stuff around. The key difference is, again, where to draw the line when deciding to launch something versus keeping it in the “hangar” until we have smoothed the absolutely last rough edge and the thing is immaculate and ready to hit the users or customers.
The platitude says that better is the enemy of good enough. There is nothing wrong about preferring better over good enough. Of course, as long as you can afford better, both in time and money. Otherwise, you have no choice but to accept good enough. But here’s some good news: the sole act of deploying good enough stuff will exert the necessary forces for it to incrementally reach better down the road. Those insisting with deploying the most perfect artifact ever conceived by humankind while having no time and shallow pockets are suicidal.
Of course, you can’t release something that doesn’t work. Therefore, there is the slippery minimum viability threshold that must be reached before something is even remotely ready to hit the road and be operated/used/consumed. There might be safety and regulatory constraints to prevent us from launching something in the wild before certain features are put in for it to be safe. But, if we are not dealing with anything too mission-critical, once we reached said minimal viability, can’t we just roll it out and perfect it further from there, with users and customers in the loop? Here’s when the ideological dichotomy kicks in; some say hell yeah, but some others say hell no. You could think of the latter as the “perfectionist” lot, but more than perfectionists, they tend to be the myope lot (and by saying this you may already guess which side I take on this war).
Minimum viability is always an end-to-end thing. My favorite analogy comes back: imagine you want to sell pizzas. When do you reach your ‘minimal viability’ as a pizza place? When the first pizza rolls out of the oven? No. If you want to make a living out of selling pizza, you will only reach minimum viability level once the oven is in place, sure, but also when you have an actual place with city approval, a way of billing, a way of packaging, a way of taking orders either from a counter, or from an app, some tables and chairs, cutlery, glasses, neon signs, printed menus, beverages, a fridge, toilets, etcetera. True minimum viability is only reached once the entire value chain reaches that viability level. It makes no sense to have one element in the chain at “perfection” level where all the rest is hanging from a thread.
Surprisingly, many engineers tend to forget that most, if not all, objects they engineer in their lifetime are part of an overarching value chain that must be at least minimally stable for it to put food on the table.
There is that phrase attributed to George Herbert—although there is no clear evidence it belongs to him—which says:
Do not wait; the time will never be 'just right.' Start where you stand, and work with whatever tools you may have at your command, and better tools will be found as you go along.
The time will never be right, and things will improve as you go. The longer you take, the more markets will mutate and the more your competitors will progress. So, dear “right the first time” gang: mind that, by the time you get out of your comfy pupal case with your shiny, perfect butterfly, things might be too different compared to when you started. The time is now.
But don’t get me wrong: I said multiple times that prototypes are not products. You cannot expect to sell something that is visibly raw like it’s the most finished thing ever. Incremental deployment needs to be combined with things like beta testing or early adopter programs, where those taking the risk of using something that is not finished get a benefit out of it. The relationship between early adopters and system developers is mutually beneficial. Early adopters often receive preferential customer support, heavy discounts, or other incentives. In exchange, their feedback and support help system designers gain traction and enhance their products for broader adoption.
Those who make real dents in markets are the ones that understand that value chains make the difference and not individual, isolated objects, as spectacular or perfect as they might be. And that those chains can grow in time; from almost laughable stages, all the way to maturity. Reid Hoffman, the co-founder of LinkedIn, said: "If you're not embarrassed by the first version of your product, you've launched too late."