What Is Technical Debt?
Did you know that Technical Debt can literally kill innovation if left unchecked? Tech Entrepreneurs and Business Executives should know about it to help build better Technology products.
Update: This post originally appeared on our HyperTrends Blog and has been reformatted just for our Medium readers.
Technical Debt is a term in Software Development that measures the costs of building something by choosing a hack/easy-fix in building software than using an approach of properly designing the software because it would take longer to release.
Technical Debt has become commonplace in majority of the tech teams that work in Agile because teams are not given many opportunities to reduce technical debt.
Technical Debt comes with a cost, just like every other debt. If you keep on incurring too much technical debt, it becomes nearly impossible to make changes later.
In our earlier articles, we have focused on Software development processes. This article focuses on this important concept that must be addressed as a part of the Software development process.
Due to the nature of Software, it is nearly impossible remedy technical debt when multiple sub-systems start depending on each other thereby making it extremely complex to introduce change without causing ripple effects.
Unmanaged technical debt, over time, is the primary reason why Software systems start to fail.
Good Teams should always set aside time to clear off technical debt.
Technical debt is incurred either knowingly (when teams are forced to cut corners) or unknowingly (when teams are technically incapable).
One could argue that tech teams always know that they are incurring technical debt as time goes on, but non-technical management rarely, if at all, acknowledges the effects of technical debt.
Management fails to allocate time and resources to reduction of technical debt. As a result, they are faced with a failing product that is not amenable to changes.
In the worst case scenario, teams are faced with top talent leaving due to the growing pains in writing quality software for systems with large technical debt.
So, What Causes Technical Debt?
- Lack of Proper Requirements — This accounts for majority of the technical debt, in our opinion. Developers are given marching orders without detailed product analysis, requirements or success/failure metrics. Majority of the developers are given instructions on a need-to-know basis. This sets up some of the smartest developers for failure. Have you worked on a project where requirements were so loose that they evolved on a near-daily basis? We bet the outcome wasn’t positive.
- Over-Promising Software Features — How many times have teams been put under intense pressure because the CEO or the Sales Teams promised features to a given customer without consulting with the technical team? Many teams are forced to work on a DEADLINE-FIRST basis where management sets up unrealistic deadlines and pushes teams to deliver them ‘under any circumstances’ to save face. This is the second largest contributor to technical debt.
- Lack of Capital — Smaller budgets tend to cause hacks. Hacks hardly work.
- Software Architecture — In many cases, the Software Architecture doesn’t allow writing quality software and increases Software debt. This is a common scenario in legacy projects. People write software that is tightly coupled with no set boundaries between different sub-systems thereby causing unintended consequences in building good software.
- Documentation — Good Documentation helps in understanding software and product. Without good documentation, it is harder to understand the prior components of the system. This is a technical debt that many teams face but never undergo steps to reduce.
- Leadership — It comes down to leadership (or lack thereof). Technical leaders are often against any sort of technical debt, whereas non-technical management seem to be OK with incurring any amount of technical debt. Leadership in general should develop a healthy attitude towards incurring technical debt and repaying it over time.
Consequences of Technical Debt
Inability to pay technical debt in a timely fashion is often a result of a business team that has little experience building tech products. The consequences vary from simple to dire.
Our personal experience has ranged from missed deadlines to overall product failures. In one case, we had to part ways with a given client because they left us with no choice.
The following patterns can be indicators of technical debt:
- Missed Deadlines
- Repeated Bugs in related areas
- Increasing Time to build simplistic software features
- Frustrated Developers. High attrition rates.
- Constant back-and-forth between business management and tech management.
How to reduce Technical Debt?
TALK ABOUT IT
It is as simple as constantly reminding management about the consequences of technical debt. “It will take us $X to repay our technical debt now, but it will take 10X of that amount after 90-days” is usually a good way to communicate with non-technical management. Expressing the same in number of days/man-hours is also a viable alternative.
DEVELOP A HEALTHY HABIT OF DEALING WITH TECHNICAL DEBT
Technical Debt is healthy, if incurred correctly. It allows a business to move with agility and sets aside time to pay it down the line. Ensure that you never drag technical debt longer than 90 days. Always track the work involved in correcting technical debt and make it a part of the overall project timeline.
DON’T BLINK
It is easy to forget about technical debt in the excitement of a high-growth company. People who forget history are condemned to repeat it. History is full of examples of companies that went down as a result of ignoring technical debt. Don’t be a statistic.
Personal Thoughts On Technical Debt
We personally feel that one should incur the lowest amount of technical debt as possible.
If one is forced to incur technical debt, they MUST clean it off anytime between 30–60 days (90 days is too long in today’s environments and can have significant impacts on Software development).
As a Software Development Company, we understand that businesses cannot easily measure the impact of incurring technical debt no matter how often they are reminded. The reason? Technical debt cannot be measured in monetary terms (until it is too late).
We also believe that majority of the businesses are extremely short-sighted as they work on a quarterly basis and want to show shareholder (or investor) ROI. This short-sightedness results in pushing for quick turnarounds and low-quality work when one reap bigger rewards by being more methodical in product development.
It is true that Software is eating the world. Majority of the systems run on software so it is alarming to see how short-sighted or ignorant majority of the business leaders are when it comes to technical debt.
It is our personal mission to work on products that incur minimal technical debt. We often build buffers for technical debt reduction in our project plans and timelines we present to our clients. When building our own SaaS products (which we often do), we ensure that we have weekly 4hr buffers to perform tasks to reduce technical debt.
We personally feel that low quality software starts growing exponentially and turns into a quagmire in no time.
With fast-paced development methodologies like Agile, if corresponding tasks for technical debt are not added in the backlog, things can quickly spiral out of control.
In closing, we hope that management (both technical and non-technical) see the value of reducing technical debt as quickly as possible to avoid negative repercussions during software development.
