Technical Debt Can Help Your Startup Grow
Why not all tech debt is bad and week 21 metrics.
Technical Debt is viewed and described in many different ways. Its purpose can vary company-to-company, product-to-product. The real key to tech debt however, is the handling of it — and that’s where we want to focus our thoughts today.
First, though — What is Technical Debt?
Let’s simplify it:
Technical debt is a one-off software hack — code that can’t be scaled or efficiently used in the future. In many cases it’s done as a shortcut to build software faster in order to meet deadlines.
Many see tech debt as a necessary evil. Building out perfect software on scalable code takes a significant amount of time. If the product being built is unproven, the best option is often to get a minimum viable product built, test the market, gather feedback and iterate. If a company invests the time into perfect code for initial product release only to find out there’s no product market fit; that is a costly loss.
Imagine, for instance, you have to run a quick product test to see if your users are interested in a new feature. One way to code it up would be adding a simple ‘IF’ statement into your main controller. This would add complexity to your code and thus, technical debt. The proper solution would be to add a new class or helper that would allow configuration and be expandable to other tests (you could even implement this in a way where you could clean up some existing logic).
The first solution (the ‘IF’ statement) would be a quick 5-minute hack, while the proper fix could lead to five hours of refactoring — a significant difference in time usage. It comes down to prioritizing product release over perfect code.
It’s termed “debt” due to the fact that at some point, those “hacks” will need to be repaired or even rebuilt completely. These rebuilds may take longer than if the software were built properly from the beginning. In essence, you’re paying interest.
That brings us to the oft-made, and obvious, comparison to financial debt. For simplicity purposes it makes sense. Take on debt, be it technical or financial, in order to gain immediate access to something. Without taking on the debt, one may never attain the desired object — a car, student loan, or version 1.0 of a mobile app.
Sure, technical debt can absolutely cost a company more money in the long run, but if managed properly, tech debt can also be a key asset in helping an early-stage startup grow.
Why Tech Debt is a good thing and how to manage it
If a CTO chooses to add technical debt to the code base in order to run a quick feature test or to help land a new client, it should be done with the full knowledge of their business counterparts along with the acceptance that this feature, if successful, will need an extra 5 hours or more of coding down the road to refactor (pay off the debt). If the experiment fails, there should also be the willingness to clean up and remove the hack. Failing to clean up will leave the code cluttered and messy, causing additional coding problems in the future.
Technical debt, first and foremost, is a means to an end. It’s a step in the process of attaining a goal, hitting a milestone, or more, getting a product to market. Tech debt is a cost of doing business. Like any expense, though, it needs to be managed.
How does one manage it?
Tech debt is not a new phenomenon. CTO’s, Engineers and technical teams have been working around it for years. Everyone has their own method of tracking hacks and ensuring they don’t cause too much damage — or interest. Some solutions are more scientific or complex than others.
Properly communicating and tracking the technical debt in your code base, leads to healthy conversation between sales, marketing and business folks. It’s better to have full visibility into the debt and inform the business team when too much is accrued.
We created Bliss to simplify the tech debt management process. Our platform monitors your code in real-time and provides analytics and action items around your software and technical debt in general.
We built Bliss because we feel strongly about the benefits tech debt can bring to an early-stage company if managed properly between both the non-technical leadership and the technical team.
However, the important point is whatever method a company chooses to manage their technical debt, the important thing is to remain aware of it and understand some code may need refactoring. Be prepared to track and publish your numbers internally — when you don’t measure and make something visible it is impossible to make the right decisions.
We have found that for early-stage companies a good base for your tech debt is 40% relative to lines of code. As the company matures, that number should hover around 20%. If a company is much lower than that, they are likely over-optimizing, which can cost in productivity and speed.
It’s difficult to put a metric around the opportunity cost of not getting to market early (due to spending time building the perfect code). The reality, however, is no product will ever be perfect or final in its first release. Changes will be made, iteration will happen.
By accruing technical debt a startup is able to play in the middle ground — build a product functional and aesthetic enough to test the market, but release it in a manner that does not burn through the company’s operating budget before getting off the ground.
The key takeaway from this is understanding that technical debt, in most cases, is a necessary evil — a means to an end. The refactoring, or extra work, on the back-end is worth it because taking on the tech debt allowed you to hit key milestones and release dates at a pace otherwise unattainable.