Beata asked a question about technical debt:

Question#

Technical debt is the most infamous poison for IT products.

At first, adding new features goes quickly and smoothly, and then slower and slower… until we end up asking: who made this mess? Why does the simplest change take ages?

So how is it?

Do good developers simply avoid creating debt, and we should focus on cultivating such habits? Or is debt like general messiness — it naturally arises as code evolves, and must be continuously cleaned up?

My answer#

There are several types of technical debt. The best kind is the conscious one, because at least we know we’re taking it on. 😀 This happens when we want to release something quickly and accept a lower (hopefully temporary) quality. If the product is going to live for a long time, we should keep in mind that we’re doing something faster now, so we’ll need to slow down later and pay back the debt.

Another unavoidable type of debt comes from insufficient understanding of the domain or simply not knowing yet what shape our code should take. I’m a fan of fixing the product state as soon as we realize there’s a better way to do something. At a minimum, at least make a decision so that future development gradually addresses it.

A much worse problem is debt caused by developer incompetence. This category is broad, but generally, you need better specialists. Hire them well and train them properly. It’s worth applying extreme programming and continuous delivery practices.

And just to be clear, sometimes it’s better to live with debt than to have a perfectly written product. Quality has a cost, and it’s often not worth doing everything perfectly.