It’s almost a rite of passage for tech companies to have some software or service you developed years ago that no longer serves your needs and is perhaps already on the verge of obsolescence.
The software was probably the result of prioritizing early deployment above all else, accumulating what’s known as technical debt; tons of it – missed opportunities for optimization, opportunities to scale that you never took advantage of, design options that you overlooked, edge cases that were never factored in, etc. The list goes on.
What then happens as time goes on, is that you start trying to close the gaps and compensate for this technical debt. Usually, this means adding more features and fixing existing bugs. However, this approach doesn’t always yield the desired results and can even trigger unforeseen issues elsewhere in the system.
This stage can be quite frustrating and will most likely push you to the point where you stew in your disappointment and think to yourself “we have to build a new one” because you’re so convinced what you have is no longer good enough. But there’s always someone else who isn’t ready to let go of the tears and blood you put into the existing version, who says “let’s fix what we have instead”.
This battle of build or fix usually becomes tenuous when the company has a new product or features to launch. Or want to expand into a new territory. Or may be getting to the limits of tech infrastructure.
So, what’s the right thing to do?
And therein lies the conundrum.
Build or fix? Here’s what my startup did
I’m hardly ever on the fence about anything but this is one of the few things I’d say I’m neither here nor there. I’ll share a bit more about my experience with what I will dramatically refer to from this point onward as ‘the conundrum’.
At my startup, Lendsqr, we grappled with the conundrum first hand. Our admin console started out on Angular 8. Anyone familiar with the framework knows how ancient this is. Naturally, we got tired of feeling frozen in time and decided to upgrade to make it better. We searched all over Nigeria, our homebase, but couldn’t find decent Angular engineers to join us. Despite attempts to fix the existing issues in-house, we couldn’t get the console to the standard we wanted.
We tried to fix it.
After trying our best to patch things and an exhaustive search for talent for over a year, which had proven futile, we opted to switch to React and it was easier to build.
Then we chose to build.
And after 9 months, we had phase 1 ready and just as it was meant to go live … I scrapped it. As you can imagine, I was bombarded with all the ‘WHY?!’ questions.
Some were probably saying “our boss has gone mad again”
My reason was simple – at least to me. When I compared all the features we had on the old version of our admin console with the first phase of the new version, it was clear that the new one – which would have also come with its own bugs and issues – would probably never catch up with the functionalities of the old console which is being improved and fixed on a daily basis. As disappointing as it was, we canceled the project.
And we chose to fix … again.
However, this decision didn’t last for long because our perseverance eventually paid off when we finally took the bulls by the horn and conquered. With renewed focus, 2 new committed engineers and a product designer, the first thing we did was to upgrade from Angular 8 to 16, revamp the design, and enhance backend functionality, all under 7 weeks. We then deployed everything to pilot phase and nothing broke. I was super impressed.
We ran the pilot phase for another month before we launched to all customers. We’re still fixing bugs here and there and adding new features.
But in the end, we had to build instead of fix.
Our experience didn’t end there, however. This happened again when we wanted to convert our core services from JavaScript to TypeScript. Our first experiment was with our Utilities microservice; a slow changing powerhouse. It was quickly done but then the devil whispered into my ears to do a massive conversion of the core Lendsqr service. It was completed in six weeks but for a very fast changing platform, it was impossible to do one massive swing and resolve all the code conflicts from the changes.
I learnt another lesson the hard way. Software is a sassy creature that doesn’t embrace all types of change and will most likely throw a fit in response.
Here’s how to decide what to do when the conundrum strikes
When Lendsqr was faced with the conundrum, we tried our hand at both approaches at different times and learnt some crucial lessons along the way. Although we eventually decided to build a new platform, it wasn’t because we felt like building, it was because we had to build.
This is an important decision in the lifecycle of any tech company and I’ll share some pointers based on my own experience on when you should consider building or when you should fix what you have instead.
When should you fix?
When dealing with a large continuously evolving application that’s core to your business like your back-office, rewriting is always difficult and you may never catch up with what you already have.
In instances like these, it’s usually better to think deeply about how you want to proceed and forget about the emotions and excitement that come with building new things. Choose to make what you have better because building from the ground up can be a real pain and the coverage required to rebuild and test can be quite crazy.
The Cost Analysis Paradox
Delving deeper into the conundrum, one critical aspect that often goes underexamined is the cost analysis of building versus fixing. On the surface, the idea of fixing existing software appears cost-effective. However, this perception doesn’t always hold up under scrutiny.
The costs associated with patching up old systems, especially in terms of time and lost opportunities, can accumulate, sometimes surpassing the expenses of developing new software. Conversely, building anew comes with its own set of financial and operational risks.
The paradox lies in the fact that there’s no straightforward formula to calculate these costs accurately. As leaders, we need to adopt a forward-thinking approach, considering not only the immediate but also the long-term financial implications of their decision.
When should you rebuild instead?
It makes more sense to choose to rebuild if the application is static with minimal changes and you can’t layer new features e.g. a payment engine.
But if you must rebuild a complex platform, I strongly recommend executing incremental fixes rather than one big revamp, to help manage the migration better. There’s an approach that people use, called the strangler fig pattern where you start replacing components bit by bit in such a way that the existing application continues until it has become a new creature, and you can shut down the old one with minimal drama.
——
There’s no one-size-fits-all method of addressing the conundrum but based on my own experience doing this, these are some of the ways that allow you to reduce your engineering risk and stay alive as you evolve.
