"First make it work, then make it right, then make it fast." - Kent Beck, creator of Extreme Programming methodology
I once had a rather interesting and illuminating discussion with someone around on some core concepts that almost every startup will deal with at some point; over engineering and time to market.
While I argued that getting your product quickly out of the door and testing product market fit should take priority for every single startup, especially the ones venturing into new territories, my friend was of the opinion that getting engineering right from the onset before anything should be the focal point.
His concern was simple, fix the engineering problem and save yourself from technical debt.
In the startup world, especially in emerging markets like Nigeria, getting your product out fast and testing it in the marketplace cannot be over emphasised. The whole idea of technical startup and digitisation, while not exactly new, our counterparts in the West have had over twenty years head start before us.
In this market, you have to, not just build, but also re-orientate people on why they should abandon their old, tried and tested ways of doing things to embrace this new shiny idea of yours.
Getting to the market fast shouldn't be taken lightly.
Reid Hoffman, Founder of LinkedIn & Partner at GreyLock Partners on shipping to market quickly. | Startup Quote
Speed and first mover advantage will win always. Not surprised he (Reid) is currently teaching a class on Blitzscaling at Stanford.
We've likely all heard may times that the customer doesn't care what is happening under the hood. She isn't interested in knowing if your data store is an RDBMS or a NoSQL data store. If your operating system is a Unix flavoured OS or a Windows server. She isn't even interested in knowing if you wrote your stylesheet in vanilla CSS or you did go the Sass or Less route.
She is interested in 2 things:
1. Does it work?
2. Will it solve my problems?
While writing scalable software and code cannot be ignored, it is imperative to note that if your product doesn’t gain market acceptability you are doomed.
Your super sleek MEAN(Mongo, Express, Angular, Node) based app that runs on 4 Amazon M3 large instances with an elastic load balancer in front of them all using a MySQL RDS and a read replica will come to nut. Nothing. Nobody cares.
Product Before Engineering
Every hyper-growth startup today all started with less over engineering and in some cases monoliths; Netflix, Uber, Spotify, Dropbox, Twitter etc all ran really large systems and in most cases all in one machine. They were all super focused on the products. They all bothered about sleek engineering after they got a strong foot hold in the market. Today, all of these startups have broken things down in favour of micro services (smaller units of systems).
You could argue that Travis Kalanic, CEO of Uber, isn’t an engineer, but I don’t think he bothered so much on how the first commit of the Uber codebase looked like. He just wanted a service that can/will allow users hail taxis using their mobile phones. Uber today is a ~$40B company, they can afford a star-studded engineering team. Heck, they poached almost all the scientist/engineers working on the self-driving car project at Carnegie Mellon University.
Why I'm Pro-product?
When Konga launched in July of 2012, we had one simple goal; retail. Our stack then was a simple Rails app that ran on a single 4GB machine. We didn’t even write the underlying e-commerce software, we used an open source solution called Spree and built upon it. No one cared. No one knew about it. We sold stuff, we were fighting an uphill battle, e-commerce, unlike today, didn’t have so much acceptability. We needed to prove to people that they can trust us with their money and we will deliver their item as promised.
Today that one machine now spans fleets of servers and we are more than anything, favouring micro-services over monolith. Why? The time is right. We have gained to a greater extent, acceptability and we can afford to settle in now and build a rock solid infrastructure.
Does Awesome Engineering Matter?
I understand why my friend favoured micro-services and doing things right from the get-go, for obvious reasons.
1. Micro services enable separation of concerns. No need to deploy an entire application when you only worked on a subset of it.
2. Scalability is easier
**3. **Deployment is a lot easier.
4. No single point of failure.
While all of these things are awesome and nice to have/do. For a brand new spanking startup, I still favour, speed, product market fit, acceptability(read as revenue) over awesome Google-esque engineering.
I live by this quote by Kent Beck - “First make it work, then make it right, then make it fast.”
A friend of mine just got into Techstars, his startup has a lot to prove.
Awesome engineering skills isn’t one of them.
Cover Image, Lagos | satanoid