The real meaning of “Technical Debt”
Ron Jeffries on the Software Craftmanship mailing list recently wrote this:
We write a test showing what we intend to accomplish, and a few
minutes later, we have accomplished it. If doing that has made the
design not quite as nice as it was before we started, we evolve the
design in place to keep it good.The more we practice this, the easier it gets and the better we get
at it.That said, there will always be times when our design ideas come too
late for immediate inclusion but they are still desirable to put
into the program. This is the original meaning of “technical debt”,
the deviation of the code now from what we understand of the
desirable design now.
I find it very clear… this explains that “technical debt” does not mean “code like hell, make a mess, hope for the best, we’ll fix it later…”. It means that, assuming I always write clean code, which means write as good code as I can, it can happen that I get an idea about how the code *should have been* organized. That may take days to do, so I don’t do it at once. It remains as a “debt” I will pay some day.
This also means that design debt is not immediately visible! It’s in the mind of people who worked for months with a project and finally got an insight. The kind of refactorings I suggested earlier might be an example of technical debt.