Does A Mess Constitute Technical Debt?
October 19th, 2009 @ 1:00 amA 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.
The original work of Brandon Savage.
No related posts.
Categories: Best Practices, TechnologyTags: , technical debtI 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.
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.
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.
Web developer, amateur photographer, traveller, and amatuer chef. Expect to find me writing code, visiting new places or trying a new recipe. I live with my wife in Olney, Maryland. Follow Me On Twitter!- Excited About PHP Again
- Rethinking The Technical Resume
- We The State, Not We The People
- Working To Defeat the Stop Online Piracy Act
- Diversifying This Blog
- What do you want the web to be?
- Why I Love Being An Engineer
- Validation Blind Spots Hurt Real Users
- Finding A Job Without A Recruiter
- Why Recruiters Are Bad For Your Career



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.