Trade offs in short term vs long term decisions
Recently I have been thinking about trade offs in product. The discussion about trade offs is something that is not spoken about much.
I was watching Season 3- Episode 5 of “Halt and Catch Fire”. The two startup co-founders are arguing about a software issue which requires a quick decision. Should we leverage the code already built by someone (a company they recently acquired) that processes credit card payment or should we build our own payment processing. The main founder is a hard core techie (Mackenzie Davis) and she argues their code is in a different language and will not fit. The other cofounder (Kerry Bishe), also an engineer but handles business, suggests it will take time to build it and in the mean time we are bleeding. Let’s put the band aid now by integrating the 3rd party code, and then we can figure out how to improve on it later. We need a band aid now to stop the bleeding.
For those not familiar, Halt and Catch Fire, is an AMC TV series about the early days of the PC industry. Season 1 starts in the early 80’s and shows the transition of an analog electrical company in Dallas, TX into the PC business. And how the protagonists (the engineers and the visionary) split up to found their own companies selling PC clones, video games and the early packet switching networking. For those who lived through the early days of personal computing, might see themselves as one of the shows characters. The writing, direction and art is brilliant. If you liked Silicon Valley (HBO), then you will surely like this series.
Back to the bandaid. There are opposing forces when you are trying to build out your software. On the one hand, you need speed. Quick and dirty code could do the trick in order to build the customer base. On the other hand, you need your code to be scalable, foolproof, extensible etc etc. Most, not all, but most engineers would always want to build for the long term so that you don’t have to go back and retool your software the expensive way later. And they can do it better than anyone else. And they also don’t want to waste time later peeling off the band aid. Hence the quest to build the right solution from the get go.
There are no easy answer to these questions. The solution lies in your goals. If the goal is to get as many customers quickly so that you can be quick to market, then yes, band aids might be the best solution. Especially, if there are areas of your product that are not so core. By all means, apply a band aid, get off the shelf tools or software. Whatever it takes to ship the software. It’s a much harder decision when it comes to the core of your software. You may decide to write code on your own and not rely on band aids. Of course, it may cost you time and customers. But you will be prepared for the eventual deluge of customers, whenever it happens. But if getting customers is key so that you can get to the next round of funding, say, then the band aid approach will need to be on the table for discussion.
When I was in a smaller startup, speed was important. We kept our eye on the long term solution because we were confident of the long term growth. But wherever needed, we applied band aid or leveraged something that we could have built on our own if we had the time. Later I worked for a larger software company. Band aids become expensive very quickly. Not to mention, that with new code being added on a regular basis, the band aid never actually gets removed. It takes years of effort to retool. Hence the need for the right solution in the first place and avoid a much larger future bleeding.
In Episode 5, the eccentric techie founder went AWOL for a week to get married. But in that week, she was able to produce code the way she wanted and it was better integrated with the core. No need for band aid.
If you can find a way to get around a band aid quickly enough, then that should be the starting point. You should always start with the longer term solution, the right solution. Understand the costs associated. Only then bring the band aid approach if the long term solution does not meet your goals.
Whatever your approach, make sure everyone in the team is aware of the decision and all pros and cons understood.
