Technical Debt
Intentional Technical Debt

Intentional Technical Debt is when you make an informed decision to take on some technical debt in order to achieve a more important goal. The key factor here is that the decision must be an informed one, not forgetting the need to handle the consequences of that decision and taking known risk factors into account.

Making an informed decision about technical debt requires some careful consideration, but it need not take very long. Skip this, however, and the consequences are likely to involve an unknown level of accidental technical debt.

Things to think about

Here is a (non-exhaustive) list of things you might want to consider when thinking about intentionally taking on technical debt.

What is the trade off?

All intentional technical debt involves trade off between competing interests. It’s valuable to be explicit about the nature of those interests - if they are ignored, you might find yourself on the wrong side of the cost/benefit ratio. Some examples:

• I’m favoring speed of implementation over speed of execution because we must not fail to have the new release ready for the October trade show in Cincinnati.

• This algorithm is going to be significantly harder to maintain than the naïve alternative but we now need to handle extremely large datasets and the naïve algorithm does not run quickly enough.

• We’ll implement this background operation as a manual process for the time being, automating it when our user base grows enough to justify the investment.

It is likely that each different issue will have a different tradeoff.

When will it be addressed (if at all)?

If your technical debt ends up forgotten, you can end up paying the price for much longer than you originally intended. It’s important to keep track of your technical debt - typically as one or more work items in your backlog (or equivalent). Some examples:

• We’ll need to implement a more performant algorithm post the Cincinnati trade show as a part of the subsequent release.

• We need to document the reasons for use of a more complex, more performant, algorithm. Also, our automated test suite needs to measure performance over some large datasets so that we can catch any degradation before it gets noticed by our customers.

• It takes around an hour for someone to do this background operation manually. As soon as we regularly need to do it more than once a week, we should automate it. We think this will happen when our user count passes 1000 active subscribers.

Different items of technical debt need to be managed in different ways - some will need to be addressed as soon as practical, some require active mitigation and some only need action as our business situation changes.

What does the business think?

While it can be extremely tempting to treat technical debt as a purely technical issue - one that you want to handle internally, within the development team - it is not purely (or even largely) a technical issue, but a business one.

Going into business involves risk - and running a successful business involves finding a delicate balance of risk and reward. If the balance tips to far in either direction, the business will fail. Many business stakeholders are therefore very good at evaluating risks and making prudent decisions for the short and long term (though, of course, some are not).

• The Cincinnati trade show is our key opportunity this year to prove that we’re a viable choice in this market. Having the new release ready for demonstration is vital if we’re to make a positive impression and open doors for our salespeople.

• Our larger existing customers are throwing larger and larger datasets at our product and performance is starting to become an issue. We have to improve performance significantly if we want to retain them as a customer.

• We have a relatively small number of active users and it is important that we put our efforts into features that will help grow our subscriber base. While that background processes is admittedly tedious and boring, it is more effective to put effort into new features at this point in time.

Conclusions

Financial debt is a great servant and a lousy master; technical debt is no different.

Effective use of technical debt can help your business move and adapt more quickly, giving you a real advantage. Ignore its effects, however, and it can rapidly become a millstone dragging you down and holding you back.

Finding the balance is important - and knowing about your debt is vital.

Prior post in this series:
Technological Technical Debt

Next post in this series:
The Maintainability Metric