Understanding Technical Debt
Pick two: build well, cheap, or fast.
This is a common dilemma faced when building new software products and features. In a time when innovation occurs at blistering speeds and the funding landscape can be prohibitively competitive, startups often opt for fast and cheap development. On the surface this isn’t such a terrible plan — if you can save 25% on your development costs and launch early that seems like a win-win. However, it’s more of a win-win-lose.
Within the piecemeal codebase of a rushed product lies inefficiency and clunk, the effects of which don’t show up until companies start scaling or adding to their product. It is quite common for companies to continue plastering over these issues while their product evolves and grows, further deepening the amount of eventual technical refactoring required.
Like financial debt, the effects of technical debt compound over time. What was once a minor database inefficiency can turn into a critical structural failure. Small patches done on legacy systems using outdated blocks may cause a waterfall of errors when interacting with modern APIs. Little bits of clunk in a codebase which cause 1-second delays at launch can balloon to 20-second delays at scale, which can be considered unusable by today’s standards.
Many small and middle market companies carry quite a bit of technical debt which when not addressed can bring their product development to a complete stop. Some technologists are of the mindset that as long as it works, who cares what’s going on under the hood? That thinking is unfortunately short-sighted. Continuing to put off technical debt can lead to lengthy, expensive, and technically complex pursuits. Maintenance costs increase exponentially while companies are simultaneously tasked with the upkeep of a collapsing product, salvaging usable parts of a codebase, and building modernized replacement parts.
Now, it’s worth mentioning, no piece of software is perfect or perpetually future-proof, and everything requires a bit of maintenance from time-to-time. Sometimes building cheap and fast is the only way to get a product launched and into the hands of users, and a demonstrable product might be the only way to unlock that seed funding necessary to bring the whole vision to fruition. It’s fine to go into a bit of technical debt to get the job done. While it is inevitable to accrue, having a plan to address it is imperative.
Like credit card debt, it’s important to start addressing technical debt as soon as you are able to, by paying off the highest interest parts first. That is to say, prioritize refactoring according to which effects will compound fastest. Foundational inadequacies should be addressed first with high-priority, speed and performance should be a mid-level priority, and smaller cosmetic components can be addressed last.
If not sure of where to start, companies will find it helpful to have a third-party conduct a codebase review and provide recommendations. Having an objective opinion from outside of the product development team acts as a fresh set of eyes on the problem, and can dissect the technical components with impartiality and wholeness. In some cases, such as with Toronto-based software development company Finnovate.io, the third-party can also begin tackling those high priority issues immediately, allowing teams to stay focused on the core product development roadmap.
Technical debt is not something to shy away from, and should consistently be under investigation. Keeping your technical debt at bay is a grueling process but important — don’t wait for the situation to become dire to invest in your product’s longevity.
Finnovate.io is a technology company focused on helping organizations build unique digital experiences on web, mobile and blockchain. Finnovate.io offers development services, training, consulting, as well as a platform that rapidly turns paper based content into digital interactive experiences.
