It’s been a long time since I’ve written an article about anything. This topic inspired me of late.
So often in the software biz, we the engineers, get tempted to lay down the ground work for something we think may happen in the future. Whether it be optimizing for performance and scale (because OBVIOUSLY everyone will LOVE our product and we will be SWAMPED with traffic), or for some future feature we think we may want down the road – after all, we can always THINK of new features much faster than we can BUILD them. If we ‘just’ do a little now, it will save us re-work later. This seems pretty logical when you look at the development cost factor in isolation. It seems like a pretty good tradeoff to spend 1 week doing something now, that will save us 4 weeks of ripping it out for something better later, right? Not so fast bucko.
What this strategy fails to consider is that in the software business, the total cost of engineering of a product is relatively cheap. For the cost of a developer for 1 year, you can build something that theoretically generates millions in revenue. So wasting 3 weeks of developer cost (re-engineering later on) in that case is negligible. However, in almost all cases, elapsed time is incredibly expensive. You’re ALWAYS racing against the clock to get that product (or feature) out the door. You’re racing your competition, you’re racing against your business plan, you’re racing against cash flow and you’re racing to keep up with customer requests. Anything you can do to get that feature or product out the door faster, serves to accelerate and increase revenue (for the period).
I read this great quote. I’m afraid I can’t remember who said it:
“Startups don’t die because they couldn’t scale – they die because they didn’t have enough customers”
Brilliant. It’s easy to forget that if you focus on getting the right product/feature into customers’ hands FAST, they’ll give you lots of money that you can then use to solve the scaling and performance problems later. They’ll give you so much money that pulling out old temporary architectures and replacing them with new high performance ones will be a pleasure. But, if you give them something they don’t like, or deliver too late (after they’ve moved on to something else), even if it scales ridiculously well and includes a whole bunch of groundwork for future features, then… NO MONEY FOR YOU!
This is increasingly true as we all become more agile and responsive to our markets – stopping on a dime and heading off in another direction. Whatever we think we know today, about what features are on our roadmap, we’ll only ever know MORE tomorrow, not less. So… it stands to reason that if we can make less architectural decisions in advance, we save them for a day when we know more – and have more money. Since knowledge, experience and cash are presumably only ever increasing, not the other way around.
The primary challenge for a startup is achieving product/market fit. This is done by engaging with your customers, pumping out features that match their requests, trial and error and ‘finding your way’ as you go. This is a bad time to be committing to long term technology investments. Otherwise you’ll likely die before you ever get to benefit from them. Performance optimization, engineering time optimization, long term product road maps – these are the challenges of a larger company with an established revenue stream, who’s biggest worry is squeezing margins. Solve those problems then. Until then, just get your work into your customers’ hands ASAP and prove that they’ll actually buy it first. Even if you have to rip it out and re-do some of it later. At least you’ll have a customer base paying you to do it.
