How to explain technical debt

Technical debt builds up in software over time. It is the summation of all the liabilities built into the technology over time. It impedes the ease of adding new features and increases the cost of keeping the product functioning. For those that do not understand technical debt, it is enraging.

Why Technical Debt is Important

Assume a software product that solves a problem that a self-referential group of people (a market segment) is willing to pay for that product. Assume that the product has just enough features (m) that results in more customers (n), consumer retention (r) and market penetration (p) that all feed directly into the recovery time of an investment (I).

These variables are at the core of a mental model that’s fairly common, and really, almost axiomatic in tech. The extra wrinkle is that when p reaches 51% of a given market, the number of features (m) needs to expand quite a bit to appeal to additional market segments. That’s (usually) the only way you achieve mass market, or getting a really high number of consumers (n).

An awful lot depends on the number of features (m).

Technical debt is an important concept because it directly interferes with the ability of a firm to add new features, rapidly, at a critical point in a firms go-to-additional-segments strategy.

The Effects of Technical Debt

Technical debt manifests itself in quite a few ways.

The first is that it causes estimates for new features to inflate beyond what the leadership was previously accustomed to. What used to take four hours worth of coding to accomplish is now estimated to take 5 days. It also causes the actual duration of delivery to inflate. What was estimated to take 5 days now takes 8 days.

The second is that it causes a lot more time to be spent putting out fires and fixing bugs than adding new features. It may have taken a team of 4 several weeks, say, 9 weeks, to produce the first 5 features. They had zero bugs to fix during that period. They launched the product, and they got hit with 50 reported bugs. Now, they’re spending 25 hours a week, each, responding to bugs.

The third is that is causes longer ramp-up times when adding to the team. More succinctly, tenure becomes the key factor of success. Gradually, the amount of time it takes for a talented individual to ramp up to the effectiveness of a median-tenured employee increases to the median.

All of these effects cause problems. Non-technical people do not understand why it now takes so long to implement a new feature, or to keep the product stable. Technical people become enraged with the non-technical people. Alienation ensues, windows break and go unfixed, and users suffer (but not for long!).

The Causes of Technical Debt

How you to keep this happening to you?

You can plan for maintenance. Price in the depreciation of the code. I it cost $100,000 to implement a feature, that does not mean you can book $100,000 worth of value. Maintenance accounts for 40% and 80% (60% on average) of a projects total cost. So, in reality, you may have to pay $80,000 to cover the cost of the depreciation.

You can plan for dependencies on technology that you don’t control. Understand that your code base does not exist in isolation from other technologies and architect the technology to compartmentalize that risk. It may use API’s that are run by other companies. It may rely on browsers that are always updating. It may have to render on devices that do not exist today. The extant that your product relies on technology that you do not control will be a factor. That adds a wrinkle in the build versus buy debate. You can buy technology, outsourcing a component that you will not differentiate upon, which is a key way to externalize technical debt. However, there’s some debt that incurs.

The third is rigorous peer review. Review the code before it leaves the dev environment and long before it gets to QA. Risks are surfaced and code is improved before it ever gets to QA. Rigorous peer review improves maintainability. Code reviews benefits everybody. They benefit the junior developers, who learn better practices. They benefit the senior developers. The practice of peer review comes at the immediate cost of time, with the benefits accruing in the future.

The choice to engage in rigorous peer review is absolutely terrific in theory, because an extra three days caused by a peer review can result in three weeks worth of time savings one year from now. In practice, sometimes that big feature event, one year from now, doesn’t even happen if you can’t get these five features in by the big trade show next month. Rigorous peer review does not replace testing.

If I had to cite the number one cause of the vast accumulation of technical debt in a short period of time, it would have to be driven by one-time, marketing based events and shifts in competitive sets.

The fourth is modularization. One large subset is the management of user login, password retrieval, registration, account management, and permissions. Those are all fairly common feature bundles. Those should be modularized and kept away from other feature sets. This not only makes it easier to maintain the code, but it also makes it much, much easier to throw out an entire module 36 months down the road.

Explaining Technical Debt

People understand time and money. And frequently, time can collapsed down into money.

All technology costs money. But it’s not just money to build. The choices made early on can severely inhibit a firms ability to respond later on.

It is a strategic activity, with very real, direct, strategic outcomes.