The “Startup Mode” Conundrum

The Eternal Fight between ‘getting it right’ vs ‘getting it out’

Being a software development consultant has an edge over other venues of the engineering discipline (like product development etc.), as one gets to work on a wide range of domains and technology stacks in a relatively smaller period of time. One also gets exposed to a variety of operational practices across organizations; for e.g. some customers have a multi-year plan while others operate iteration to iteration. Some clients are open to change, while others are entrenched. Although I am a fan & proponent of XP, I believe it’s not for everyone, right from individuals to corporations. In fact it’s quite difficult to get XP right.

As developers, we want to write the best possible code, with a rich test coverage, a robust CI/CD workflow and a well-monitored infrastructure.

There is no one size fits all solution to software project execution from an engineering perspective, as it differs a lot across the industry spectrum. This offshoots into an interesting problem when a client has tight deadlines - sometimes it’s a rescue project whose result could make or break their business. Now as developers, we want to write the best possible code, with a rich test coverage, a robust CI/CD workflow and a well-monitored infrastructure. But quality takes time and talent. Let’s assume for the sake of this argument that all developers are highly competent; quality then becomes a function of time. Ironically, startups are strapped for two things, time and funds.

Let’s look at this problem from a typical early to mid-stage startup owner’s perspective. They want devs to push features fast and with high quality. Do you see the contradiction? As discussed above, quality is proportional to time, but we want to ship things fast! The Product Owners (PO) ask the engineers to cut corners and ship without tests or enough QA. But this directly affects quality and user experience. This is especially painful when one is a consultant for such a startup, and is exacerbated when the POs are non technical.

I would like to stress that no one is wrong in this scenario, devs want to ship top notch stuff, but if the business won’t exist till the time the software is ‘top notch’, it’s futile anyway. We are not building software mausoleums. This is a classic conundrum I have faced in my career a few times. I am yet to find a sustainable solution.

Let’s look at some examples; Twitter started out as an RoR application which later had to be migrated to the JVM due to scalability & perf issues. Facebook was a PHP spaghetti to begin with, which needed the HHVM later. There are numerous examples, from LinkedIn to Airbnb that started with high tech debts, because the need of the hour was speed. However, they did have to pay the debts later and had to slow down. Tech debts bite big time if ignored.

In conclusion, there is no single solution to the aforementioned quandary, there are only trade-offs, in fact I dare to claim that most software engineering is a fine balance between axiomatic but incompatible options.