Ward Cunningham coined the term technical debt. In 1992, he said: "Shipping first-time code is like going into debt" (source). Like borrowing money from the bank, a small amount of debt is fine as long as it's paid back!
Cunningham continues: "The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt."
Most importantly, he ends by saying, "Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored implementation."
In this post, we are going to examine technical debt and why it is a startup killer. Let's jump right in. If you have questions or comments, reach out to us via email.
What is Technical Debt?
Dan Radigan says: "Technical debt is the difference between what was promised and what was actually delivered" (source).
Any engineering team will have some level of technical debt, even the company that has raised a fresh $1 billion from top tier investors. And, as we said earlier, some debt is OK.
The problem arises when your team has a culture of hiring junior talent, writing poor requirements, rushing to meet deadlines, and incurring unnecessary or unaccounted technical debt. For example, imagine you are building a web application for the financial services industry.
You make your initial release and things are going well. But then a host of users request for the ability to invite team members to your platform. Your team rushes to push the new "invite team members" feature out. Then, a few weeks later, users come back and request the ability to have fine-grain control over what users can see and do in your app.
You go back to your engineering team but they let you know that invite team members, account types, and a whole host of other things that need to be redone before you can implement this latest feature request.
This is a practical example of technical debt. Along the way, you need to move fast but you also need to have one eye to the future and repay that debt!
Put more succinctly, technical debt is the gap between the ideal code written for a product or feature and what was actually shipped.
How does Technical Debt Accumulate?
Technical debt accumulates for two main reasons: (1) resource constraints and (2) poor management.
For instance, the company leadership may be asking too much from the engineering team by either pushing junior talent too far or not giving senior talent enough time to properly implement solutions.
Either way, engineers will feel the crunch and important items – like refactors and bug fixes – never get prioritized.
At this point, it makes sense to clarify between temporary technical debt and permanent technical debt. If you have to meet a release deadline and incur some technical debt along the way, that is acceptance. Technical debt should be well-understood and temporary.
That means that business and engineering leaders should understand there is technical debt, where it is, and that it needs to be paid down in the future. In this case, poor management means wanting to run as fast as possible without having your shoelaces tied.
Good engineering management do not strive for zero technical debt. They strive for well-structured, documented code and well-understood, temporary technical debt.
Why Technical Debt Kills Startups
Most startups start off incurring massive amounts of technical debt.
This is because they are building the project with sweat equity with junior talent that are willing to work for experience. However, there are other reasons technical debt accumulates in startups.
For example, a demanding board of directors, unrealistic deadlines set by founders, or large pivots that are not properly scoped.
The core problem is that many startup leaders do not understand technical debt – nor do they realize that they are incurring massive amounts of debt that must be repaid. Debt that is not repaid will slow down a team attempting to make progress.
And, to make matters worse, technical debt will rear its head at the most inopportune moment, which leads to botched product launches, poor user experiences, damage to brand value, or missed revenue.
Conclusion
As we mentioned, technical debt is not something that needs to be completely avoided – it's a natural byproduct of the software development process. But it is important for technical debt to be understood, minimized, and – above all else – repaid.
Tragic Media has architected, built, and supported applications for industry-leading brands. We understand what it's like to ship products used by tens of thousands, or hundreds of thousands of users. If you are looking for more guidance on best practices, contact us today for a free consultation.
We look forward to help you build the next game-changing application.
