As a founder and leader of a tech startup, you have a million different things going on - constantly. You’re pressured from all sides - your customers, your investors, your team. You do everything in your power to build your business into a great success, which sometimes looks like a valiant leap into the vast unknown, and sometimes more like a fighting crawl up a jagged slope, covered in lava. The thing is, you’re doing a terrific job.
What if I told you that technical debt could turn out to be the grim reaper itself, jeopardizing all of your hard-earned growth and success?
As a technical founder or leader, you might instantly recognize the importance of assessing and paying down tech debt, but you might see a tough road ahead to convince your colleagues that it’s worth spending money to fix what already exists.
As a business leader, you may have just rolled your eyes. “How could tech debt throw that big of a wrench into things?” “If it ain’t broke, why fix it?” Or, you might be asking “what is technical debt, pray tell?”
DEFINING TECHNICAL DEBT
Technical debt, originally coined by Ward Cunningham in 1992, has come to have many faces. Whether you adhere to its original use as a way to justify an iterative, experiment-based approach to software development, or the more contemporary definition as “any code added now that will take more work to fix at a later time - typically with the purpose of achieving rapid gains,” technical debt remains a powerful software design metaphor that highlights the compromises between the short term gain of shipping features fast, versus the long term viability of the software system. Technical debt provides an explanation for the economics of refactoring - the continuous learning process of developing software.
Technical debt has many faces, indeed. The “debt” being accumulated over time can be technical (obviously), financial (I bet that one got your attention!), and even organizational - all of which are usually inexorably intertwined.
RECOGNIZING THE FACES OF TECHNICAL DEBT
“We used to ship new features in two weeks, and now it takes more than 12 weeks!” - sound familiar? This is what an actual client said to us, when they first approached Corgibytes for help.
Systems plagued by technical debt will often see their end users frustrated with bugs, the amount the amount of time spent waiting for improvements to the software, and newly released versions that don’t work right. At the same time, developers are frustrated working with the code and with areas of the codebase they are afraid to touch, which in turn leads to decreased productivity and motivation.
Software that never needs to be updated or upgraded, and yet is always up-to-date with current trends and demands - or, “dream software” as Daniel Okwufulueze calls it in his piece Dealing With The Inevitability of Software Entropy, simply doesn’t exist. Any existing software system that is in use faces constant pressure to change, and with that change comes a buildup of pesky problems.
This one is largely self-explanatory. You have probably already drawn the conclusion between the list of tech-debt challenges above and the bottom line, and the threat that these issues pose to the company’s future success, growth and sustainability.
While the justification of “fixing what isn’t broke” is understandably difficult to swallow, technical debt cannot be ignored from a financial perspective. To paint the simplest of pictures, in the worst case scenario, the software applications get so choked up with technical debt and entropy over time that changes cannot be made anymore, and nobody on the development team is willing to touch the codebase anymore (this is an exaggerated extreme, but we’ve seen things close to it). At that point (or anywhere along the spectrum), your consideration becomes the (monetary) cost of scrapping everything you have and rebuilding from scratch, or, as Corgibytes tends to favor, salvaging everything possible from the legacy app and remodeling something out to a clean, accessible stage.
Spoiler alert: you definitely don’t want to find yourself in that situation.
Since we’re on the topic of money: startups are very much in the game of borrowing. Borrowing money, borrowing resources… even borrowing time. If you’re going the venture backed route, it is already a given that in exchange for investment now (of capital, time, resources, expertise, etc.), you’ll pay back those VCs down the road.
Paying down technical debt should be equally prioritized, and central to paving your path to success. Just like financial debt accumulates over time if unpaid - via interest rates and other mechanisms - technical debt not only accumulates, but also continues to get uglier (and more expensive) the longer it is ignored.
Technical debt always reflects an operations problem.
This brings us to consider the connotation of communication debt. If barriers in communication exist and are even exacerbated over time, CTOs and technical leaders aware of technical debt challenges often find it impossible to communicate those challenges to the people holding the wallet, and/or the reins.
Thus, a lot of companies don’t move to address technical debt until it starts crippling day-to-day productivity, and by then it can be very expensive to pay down (which, feeds right back into financial considerations).
WHY ALL OF THIS MATTERS FOR YOU
As the leader of a startup, you might now be asking “well, my company is only X years old. How could my codebase possibly be that bad? How could we have technical debt already?!”
If you’re currently on the fundraising trail - whether it be for a Seed, Series A, B or later round - you want to have your ducks in a row. If technical debt wasn’t on your list of priority issues, it’s a great time to add it. You will head into technical diligence with prospective investors with so much more confidence, knowing (most importantly) what technical issues, roadblocks and challenges you’re currently facing, and having some sort of plan in place (if not already executing) to address and overcome them.
If you’re completely bootstrapped or revenue positive and don’t need to seek institutional funding, then your investment in paying down technical debt will be less about impressing at the next investor committee, and all about ensuring that your business is in a place where it can scale the way you envision, and continue on its path to success.
“Moving fast and breaking things” is a hallmark of the startup ecosystem, and rightly so. Speed, agility and the hair-on-fire drive to delight customers and build a unicorn are the attributes that make startups - and their fearless leaders - so awe-inspiring. However, all startups hit an inevitable inflection point, where regardless of the shift in working style (not suggesting it has to be a jump to “slow and steady wins the race”), the codebase that got you to where you are now is not the codebase that will take you to your next phase of growth, and beyond.
Just as an incredible amount of work went into getting you where you are today, there is still much work to be done to continue your journey for ultimate growth and success.
TACKLING TECH DEBT: WHAT CAN BE DONE?
“We need to stop thinking about debt as evil. Technical debt can be very useful when you’re in the early-stage trenches of designing and building your product.” This is how our Co-Founder and CSO, Andrea Goulet, thinks about technical debt, and takes a deep dive in her interview with First Round Review: Forget Technical Debt, Here’s How to Build Technical Wealth. “When you resolve some debt, you’re giving yourself momentum. When you install new windows in your home, yes you’re spending a bunch of money, but then you save a hundred dollars a month on your electric bill. The same thing happens with code. Only instead of efficiency, you gain productivity that compounds over time.”
If you treat paying down technical debt as building technical wealth instead, you’ll soon start to see the world (and your technical roadmap) from a much brighter, glass-half-full perspective. Most importantly, you can fully justify every decision to clean up your codebase, refactor, add test coverage, patch security vulnerabilities, and upgrade your dependencies as crucial investments in your business and company as a whole, leading with scalable, stable, and secure software.
DON’T USE BAND-AIDS
Quick fixes are rarely an ideal long term strategy, and prove to be highly unsustainable in the world of (legacy) software.
Uncovering and deleting dead and redundant code, cleaning up while making changes, and continuously looking for ways to improve the codebase as you go, are among the top D.I.Y tips that Corgibytes’ CEO, Scott Ford, proposes for high growth development teams.
If you feel stuck, are keen to strategize a modernization strategy leading up to an important fundraising round, or simply want to talk through some of your frustrations and fears around technical debt, we are glad to have that conversation with you. As genuine lovers of legacy code and true menders, Corgibytes’ team would be delighted to help you transform your technical debt into technical wealth!