Technical Debt is not a Technical Problem
It’s the beginning of the year and perhaps because many fear a recession and there is a concern about operational efficiency, there seems to be a lot of discussion lately about technical debt. That’s a good thing. For too long people have talked about technical debt as an engineering problem.
Tech debt is a business problem.
Ward Cunningham developed the term to explain to some non-technical people why resources needed to be allocated for some engineering work. It seems like it would be a good metaphor as many of us understand that debt often carries interest and as that interest accrues, we accrue more debt. However, for business and finance people in the context of the business (as opposed to their personal lives), debt can be a wonderful thing. It can provide us leverage which among other things allows us to have a longer runway for our startup. It can allow us to open offices in new geographies or expand our offerings onto new continents. Debt can be very useful. In certain business contexts, if we have a lot of debt we can package it up and sell it! Of course, this is not how tech debt works. It cannot be packaged up, or sold, outsourced, or purchased from a SaaS provider.
Tech debt is also not inherently good or bad. Obsessively trying to eliminate all technical debt will almost certainly run quickly into the Pareto Principle where 80% of the debt is a result of 20% of the problem and trying to eliminate the last 20% of the debt is almost certainly not an economically prudent course of action.
At a startup this can be fatal. Startups are trying to achieve product market fit and break through to profitability. Spending a lot of time on hyper-clean technical implementation, rather than on survival in this situation is downright foolish. Startups should take on lots of technical debt in service of survival. After the product, the market, etc. are well understood, can we begin to determine the “right” way to architect, build, and continuously deploy the application.
In a business that has moved past the startup stage, tech debt can be a drag on the organization’s ability to execute. In this context, tech debt is a business problem. This is the context in which Cunningham (one of the authors of the Agile manifesto) was concerned. If the business chooses to accept the reduced velocity in this case, then that is a business decision. It is a decision about the current conditions and the business’s ability to compete.
I generally break down tech debt into two classifications: known and unknown.
The tech debt that is a problem is generally the debt that is unknown. This debt comes from insufficient testing, documentation, training, planning, etc. This is often the debt that most often causes outages, weighs on development velocity, and causes us to miss our targets causing further damage down the road.
Known tech debt is a lot more like actual debt. If we know that tech debt is causing the problems listed, but choose to do nothing about it, that is a business decision. I hear so many engineers complain that management doesn’t give them time to pay down technical debt and how they are suffering for it. However, it’s also the business that is suffering for it.
When we choose to run 12 different datastores that can probably be merged down to a handful, that is a choice. In this case, we are knowingly making a decision to pay more, and get less from our data storage layer.
I firmly believe it is actually ok to take on tech debt as long as it is identified and acknowledged. We can acknowledge that we will suffer reduced velocity in the short term while we make a business decision to do other things.
It is also important to note that this debt will not fix itself. We cannot expect engineers to work on it as a side project, or on their own time. Just like with monetary debt, there must be a conscious decision made to pay it down, even if it’s a little bit at a time every month. Just like with monetary debt, it will continue to accrue until it is unserviceable. Business decisions need to be made to maintain a velocity that will not damage the business itself.
When engineers know that they are being heard, and that their message is actually understood, they are much more willing to live with some amount of technical debt for a period of time. Accumulating debt (financial or technical) is best done with eyes open, with a smart payment plan that satisfies our financial, technical, and organizational needs, and enables the business to flow.