Sowmyanarayan Raghunathan
In 1992, Ward Cunningham coined the metaphor “technical debt” to highlight how businesses weigh their short-term gains against the long-term viability of a software product. Business dynamics have evolved a lot since then, but the metaphor still works.
Favoring a short-term plan to get a faster go-to-market option is not always bad, provided the business has a backup plan to deliver well-designed code that would simplify future iterations and innovations.
But for startups, reworking is difficult as deadlines and resource crunch prevent developers from producing clean and perfect code. Startups prioritize short-term plans and focus more on adding functionalities to achieve milestones, sign up marquee customers or raise funding. This roadmap shuffling and disregard for the long-term view trigger tech debt.
I have worked closely with more than 25 startups and learned a lot from their journey from early-stage to growth stage. I have realized that avoiding tech debts becomes easier with some ground rules.
Here are four rules that startups should follow to avoid tech debt:
Don’t let specific implementations continue for over three months
Startups often try to customize their product to meet their marquee customers’ demands. Sometimes this leads to two products — a generalized version and a customer-specific one, and converging them becomes difficult over time.
To stay on track, companies start cutting corners, which destabilizes the product. I have seen engineering teams work on customization for a whole year and then lose 20 months in merging and stabilizing the core product.
Startups generally work with an 18-24 month runway before they raise the next level of funding. If they rework to generalize features, they could lose a costly quarter to stabilization.
What to do:
When teams work on custom features for more than the specified timeline, merging them back with the core product becomes complex. It is better to acknowledge that products cannot be customer-specific at the very beginning. Startups should consider the platform and think about future maintainability upfront.
I have experienced these problems while developing products for my customers. That’s why I do not let any specific implementation continue for more than one quarter. Making those features a part of the mainstream product is of utmost importance. This practice ensures that we add the features to the core product before the developers forget why the specific feature was built in the first place.
We followed this method for an email marketing platform where our developers followed a strict timeline to deliver custom features and incorporate those in the core product within a quarter. The plan worked and it helped the platform acquire more customers.
Do an architecture review of the product every 18-24 months
Startups hardly get 18-24 months to raise funds for the next round. This keeps them so engrossed with adding new features that they start ignoring design, versions, technologies and architecture stability.
Consequently, the foundation begins to crumble and accommodating new features becomes challenging over time.
The foundation of any software product is directly responsible for better scaling and maintainability. It comprises technology and architecture, and if they are right, feature addition becomes easier.
What to do:
Review the product architecture every 18-24 months and highlight the technical debt accrued due to old and outdated tools, languages, frameworks or methodologies. We did this with a SaaS product in the recruitment space. The areas of improvement identified by the review helped us quantify the impact on the scalability, availability and maintainability aspects, which helped convince the product owners to have the upgrades included in the product roadmap.
With this approach, understanding where the problem lies and how to help them get out of that situation becomes easier for product owners. This approach is also financially rewarding as the alternative — a complete rearchitecting of the product — is quite expensive.
Upgrade to new open source versions two months after launch
Startups, as they don’t have many paying customers in the early stages, worry a lot about their product and ROI. Some even work without investors. Using open source software is a cost-effective way to build products.
Adopting open source software requires teams to constantly upgrade to newer versions. Skipping one upgrade may not cause trouble, but skipping multiple version upgrades could lead to tech debt, which could consume substantial time to resolve.
I have seen startups losing almost a quarter of a year because they fell behind on upgrading their open source software.
What to do:
Upgrading open source software to more than two major versions can require around 25% of a team’s yearly bandwidth. In contrast, regular open source software updates can reduce cost and free up developer capacity with built-in features.
The engineering team should be aware of the next major change beforehand, as it simplifies upgrade planning. In the case of APIs, the system will fall apart if the team doesn’t upgrade in time. When the upgrades concern libraries or frameworks, wait for a month or two to understand how people are reacting to the upgrade. If the change gets a positive review, stabilize it and then incorporate it into the product.
We upgraded Angular for a real-estate investment platform from version 5 to 11, which reduced load times and improved user experience. The site now loads in less than two seconds and has given the platform a much-needed improvement in user experience.
Understand the product and identify NFRs in advance
Engineering teams often get little clarity about a startup’s future, which prevents them from making certain architectural decisions. For startups, ROI is so important that teams might have to satisfy medium-term needs first and step away — even when there is complete visibility — from implementing complex solutions.
In one such case, I was working with a customer with a regional reach. We were managing the data with batch processing. But then, with the rising investment flow, the customer decided to go national. This increased the volume of data, which managing with batch processing became difficult. Ultimately, this mismatch amassed tech debt.
What to do:
Engineering leaders should be aware of non-functional requirements (NFRs) to avoid complete re-architecture. Re-architecting a product is not easy as it takes months. In addition, working on re-architecting and simultaneously serving existing customers requires monumental effort.
In the example above, if the team knew about the NFRs early on, they could have used a solution comprising paid services rather than managing it independently. This would have ensured the system’s scalability.
The initial infrastructure cost is marginally higher, but it’s worth the price considering that the product’s architecture is right. Later, you can change the tooling to manage cost. For one of our customers, we built a serverless solution from day one, as we knew the NFRs clearly and wanted lean infrastructure. This was done with a team of only three developers.
Comment