We are living through an era of increasing innovation and incredible investment in start-ups of all industries. It’s a profound time to be a technologist and entrepreneur. It’s also incredibly competitive and if you and your technology can’t move nimbly, your business will likely sink.
While industries everywhere are exploring how to tap into new markets or expand existing ones.. the technology and its implementation are critical to allowing a business to experiment and make fast decisions on direction. Getting bogged down in a tech stack that is difficult to perform experiments with is not an option and will lead to competitors putting you out of business.
I’ve spent the last 5 years working with start-ups of all sizes. It was imperative for every one of these to have the technical agility to experiment with an opportunity, tweak it, note results, and repeat. Many are able to do this.. but many more are not.
Are typically just starting out. If you’re building from scratch.. you don’t have a whole lot slowing you down.
It is unfortunate, but every start-up I’ve encountered and worked with that was more than 3 years old, had some form serious technical challenges impeding their speed. They were unable to capitalize on many or most opportunities presented to them. This is a recipe for failure.
It does happen that a start-up has both moved quickly in the early stages and continued to expand its technology through that growth without resulting in crippling technical debt. It’s rare though.
This article is not going to focus on how you achieve an agile, maintainable, expandable technical stack from day one and keep it through year five and beyond (though I’ve executed on teams achieving this, it is possible).
Instead, we’re going to look at how a business and their tech stack can move from a crippling slow speed of engineering to one where your technology is able to facilitate business exploration and growth with ease. I’ve seen it done. It doesn’t happen overnight, involves significant trade-offs.. and can be a myriad of combined strategies.
We’re talking about the scenario where a business has gradually found the flexibility of their tech stack decreasing and they’ve reached the point of ‘Ok, we’re ready to do something about this: shift things and make compromises to increase flexibility for business capacity or expansion.’
Understand the picture
Look at the entire tech stack. Where are things slow, why? What are the critical areas that if improved, would allow for the most exploration of the product?
Metrics are key and we’ll dig into those later. Gather metrics about where time is being spent and talk to engineers about what are the most painful areas of their day-to-day work.
The concept of refactoring is now a prevalent one. And rightly so. It’s a powerful tool in the toolbox for keeping code clean & consistent. It’s also a learned practice and becomes increasingly challenging to do well when dealing with a particularly messy/complex codebase.
In cases where the components slowing down engineering are large, messy, complicated and inconsistent codebases, it can actually be more expensive and risky to take on a refactor only strategy.
The idea of refactoring is easier for a business to deal with. Often, you’ll see teams come up with a strategy of specifying how much time will be spent on refactoring. ‘We’ll spend 20% of our time on refactoring.’
The issue with this is that it’s not a valuable metric for how much enablement the tech is providing to business exploration and success. This team could be spending 20% of its time on refactoring and still be squeaking forward with new features or capabilities for the product and its users.
A codebase rewrite is a difficult pill for a business to swallow. The idea of throwing away code that a lot of resources have been invested in is tough and feels wasteful. There’s also the likelihood that there will be a longer wait for those new exciting features while the current functionality is re-examined and re-implemented.
At the center of this effort is often the realization that too much time is sunk into each new feature.
Ideal feature development in terms of effort spent on each stage of development should look something like this.
In a situation where perhaps just a targeting refactoring strategy might apply, your relative effort may look like this.
In a situation where it’s perhaps going to be more expensive to refactor than rewrite, your relative effort could be more like this.
Any new shift in strategy carries risk. Evaluating risk from the outset is critical in minimizing waste and arriving at the new improved architecture that will propel your business forward. These are the top risks to keep in mind:
Take the time to setup accurate tracking here. It will allow you to reach the right decision in strategy and provide visibility into whether your efforts are delivering more business value later on.
Be it a long term refactoring strategy or a complete greenfield rewrite, it’s imperative to have a diverse team of talent. It’s ideal to have engineers who’ve undertaken the path you’ve chosen. Having this will significantly increase the likelihood of ending up with a clean, consistent, improved architecture at the end of your efforts.
From the product manager, UX designer, all the way to the CEO.. what’s going to spell the most success is involvement from all and visibility to all in the decision and progress in the rollout of that decision.
This article started out by introducing the idea that for start-ups to succeed, they must be able to experiment quickly in new potential areas of serving their customers.
If they happen to be hindered with a shoddy tech stack that makes this kind of experimentation extremely expensive, they are likely headed for failure (without some sort of course correction).
The options available are many, but span some form of refactor or rewrite. And this decision could be different across all parts of the tech stack causing problems. You may selectively choose to rewrite a portion and refactor a portion. Perhaps rewrite your APIs, but refactor your clients. It all depends.
Many time, however, a rewrite is not tackled as it is deemed to expensive in the short term. You often have to spend resources not only to build out the new, but maintain the old.
What’s at the root of the argument put forward in this article is that it’s often quite a bit more expensive and risky to refactor an inefficient and difficult to manage codebase. It takes the right technical leadership and team. And if you happen to have the team who are capable of this, you may spend more time still taking the codebase to the place where that fast-paced experimentation is possible.