Tech Debt Is A Messy Closet - Part 1

If there is one thing programmers love when talking about programming, it's a tortured metaphor. Of the many things programmers dislike, it's tech debt. What better way to talk about tech debt than with a tortured metaphor of a "messy closet"

Tech debt is like a messy closet because, like with a messy closet:

1. Most of the public will not know how messy your closet is, or the nature and severity of your application's tech debt.
2. The state of your clothes in your closet isn't what people notice directly, the amount of tech debt you've incurred is not what people notice in your application.
3. People do notice when your clothes are wrinkled, don't match, don't fit well, or are not clean. People do notice when your application is buggy, doesn't get significant updates or features, or doesn't perform well.
4. Your partner may want to know why it takes you so long to get ready to go out on the town, your managers and teams you partner with may want to know why it will take so long to reach a given milestone.
5. You can continue to get by with a messy closet, and you can continue to get by with tech debt. You have to decide whether you value a clean and organized closet and whether you value a clean and organized code base.
6. A closet doesn't need to be perfectly organized and not all tech debt needs to be addressed.

Some sources of tech debt include:

• Lack of developer experience, not following conventions and best practices, or not having clear design to begin with
• Schedule pressure or other urgency that requires a fast solution instead of the best solution.
• A change in requirements of, or assumptions made by, the code.
• Time and the number of developers altering a given area of the code tends to erode all but the strongest designed and documented code into fertile ground for tech debt.

In 97 Things Every Programmer Should Know: Collective Wisdom from the Experts, we may read a variety of viewpoints on the source of tech debt, even when the authors are not directly writing about it.

Klaus Marquardt writes:

The reasons for their creation are many and varied, but the key to an interim solution’s success is simple: it is useful.

I like this viewpoint because it can help us avoid a frequent, but non-productive tendency towards "code shaming". We've all come across something "totally wrong" and maybe even sworn under our breath. Worst of all we may have code shamed something to a colleague and it was their code or made them more afraid to make mistakes and learn or even to work with us for fear of needing to achieve perfection.

Robert C. Martin (Uncle Bob) has a more strict view of professional software development:

Imagine that you are having an out-of-body experience watching a doctor perform open-heart surgery on you . This doctor has a deadline (in the literal sense). He must finish before the heart-lung bypass machine damages too many of your blood cells. How do you want him to behave? Do you want him to behave like the typical software developer, rushing and making a mess? Do you want him to say, “I’ll go back and fix this later”?

It's important to put things in perspective. If we're talking about mission critical code, then by all means, the standards should be higher.

Of course metaphors are all fine and good, but eventually we need to focus on what to do about tech debt. To be continued...