Does A Mess Constitute Technical Debt?

A blog post over at Object Mentor argues that technical debt and a mess are not necessarily the same thing. This well written blog post discusses the difference, and asserts that taking out technical debt is like taking out a mortgage: that you increase your discipline, rather than decreasing your financial discipline. The same should be true of technical debt, then.

I would tend to agree that a mess does not constitute technical debt. A mess is just a mess, most of the time. Writing poor code or having a project filled with messy solutions doesn’t incur technical debt; it pushes you towards technical bankruptcy.

However, messes are not always simply messes. Sometimes you have the choice between doing it quickly and doing it well.. This isn’t an optimal situation; however, it is an intentional design choice on your part. Writing a hack incurs technical debt, and hacks are almost always ugly. If you had time to write it correctly, you would write it cleanly, and it would incur less technical debt.

Technical debt accrues based off of your own choices. Just like how you don’t accidentally get into debt with finance, you can’t accidentally accrue technical debt. Technical debt is a choice, requiring you to decide between two options. Implementing a messy solution is a choice as well; doing so will only increase your technical debt, in much the same way that adding closing costs to the overall mortgage amount will increase your debt.

The accrual of technical debt is a necessity, especially when deadlines are considered and people have to make quick decisions. But technical debt is a choice; you do not accrue it accidentally.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

chris (@enygma) wrote at 10/19/2009 1:43 am:

Accidentally? No…but it’s still possible to inherit technical debt. It’s never a fun situation when you drop into a job and there’s already this huge mess to deal with (especially if you’re the one tasked with cleaning it up).

It’s sad that deadlines are such a deciding factor in so much of the software development done these days, but there are things you can do to help minimize the effects of them like making code easily extensible and working with modules and fight the urge to hard-code.

Samuel Folkes (@SamuelFolkes) wrote at 10/19/2009 2:22 am:

I have to agree with Chris here. Inheriting technical debt is increasingly becoming a problem for developers, particularly when working on projects being managed by technically inept project managers. I’ve had to walk away from several projects where managers just want the system to work with little or no regard for important aspects of development such as application security and API documentation. To them ignorance is bliss. In many scenarios the debt isn’t accidental nor is it unavoidable. Its simply not acknowledged.

Brandon Savage (@brandonsavage) wrote at 10/19/2009 2:31 am:

It’s completely possible to inherit technical debt, that’s for sure. I know I’ve inherited technical debt many times. However, the accrual of new technical debt in a project is generally not accidental, but a choice.

Kris Hardy (@krishardy) wrote at 10/24/2009 11:44 am:

Agreed.

I’ve run into really nasty situations myself. First, a client has a serious technical debt that was handed to me to manage. The debt is so massive, he would have actually been better off writing-off the debt and starting a brand new development project from the ground up.

Now, the client wasn’t interested in doing that. They don’t understand anything about architecture or development, they just want to add new functionality to their current software as quickly (and cheaply) as possible.

In that case, unfortunately, you have 2 choices… You hack in the improvements as cleanly as you can, or you walk away. And I have done both.

However, walking away sometimes isn’t a viable option, and you’re stuck doing debt control. It sucks, but sometimes it’s unavoidable.

Copyright © 2023 by Brandon Savage. All rights reserved.