TODO: address the debt

Delivering a product requires balance and often requires sacrifice. On more than one occasion I found myself saying something like this: “<insert objective> is important, perhaps fundamental to our vision/technology. However, we must deploy to production in <insert too low of a number> days, and so we make decisions that are sub-optimal but get us to market on time. It is a sacrifice, but we will recover as we make a backlog TODO item to address each sacrifice.”

Sounds good, right? As Mik Kersten states in Project to Product:

“additional technical debt could be taken on in order to allocate more flow to delivering features instead of reducing debts.”

It’s a good balance. A valid approach to purposely take on debt for a higher priority. Sadly, as I have learned, it can be a dangerous one.

Often the TODO fixit item gets deeper and deeper in the backlog as more business features get prioritized. As more are prioritized, we get more debt and more debt adding to the backlog. We see similar contributions to technical debt including life-lessons on architecture, frameworks, poor code, an implementation that works but is difficult to adapt to new business, etc. This is why Dr. Kersten elevates technical debt into a flow item (Feature, Defect, Risk, and Debt) to be aware of and ensure it is addressed at the appropriate product delivery timeline.

Quite often technical debt is as innocuous as something we did not know we did not know, but now that we know, we know it’s a problem (e.g., performance, scaling, rule flexibility, UI behaviors, etc.). Sure we can get by, but what happens when that backlog feature continues to get discarded, never gets implemented, and remains a wart on your product?

This mounting technical debt creates an un-enhanceable product after a time, but (1) too few understand this, (2) management turnover is often sooner than the fallout of mounting debt, so by the time it is an issue it is someone else’s issue (the poor soul now holding the bag), and (3) new features are often the only perception of business value, and so the blame game continues.

Technical debt is not a wart, it is a tumor

Tumors must be dealt with or they will consume you. The product team must educate their stakeholders. Explain the impact of mounting debt; impacts to estimates, new features, defects, work arounds, training, end-user discord, etc. Any product that is not at end-of-life must account for technical debt as part of the expected norm or suffer from a crushing, terminal tumor.

It is incumbent upon executive leaders to learn why technical debt exists, why it must be addressed, and how doing this will improve your workforce and your bottom line.

The perspective that IT is a cost center, not a profit center, is a major driver for this discord. As a cost center, the only investment is in new features. The side effects are discounted and often placed into IT Operations budget which, of course, is never sufficient to do anything but deal with the urgent fires of today’s meltdown. Debt is considered failure and defective, shoddy work. Blame is a currency in the cost center.

An IT profit-center perspective recognizes the positive value of purposely trading debt for investment. Like economic debt, technical debt needs to be viewed as a consequence of doing business. Just like economic debt, you are exchanging technical debt for an asset of higher value. Build software, take on debt, pay down the debt, have a stronger product and a more engaged workforce.

Whether economic or technical, you can ignore debt only so long before the piper comes calling. How much you pay to the piper…well that’s up to you.

As I finish writing this I got an e-mail with this very apt article to read, please take a bit of time and review this as well: https://techbeacon.com/devops/how-avoid-technical-debt-kiss-death