"技術的負債"ということばは Ward Cunningham 氏が最初に考え出したものだ (氏自身のことばによる説明が公開されている)。
最初のコードを出荷することは，お金を借りることに似ています。書き直してすぐに返済できるくらい負債が少額であれば，開発が速くなるのですが ... 危険が起きるのは，負債を返し切れないときなのです。負債の利息としての決して良質とは言えないコードのために，すべての時間が費やされてしまいます。借金で負わされる散発的な作業のために，技術組織全体の活動が停滞してしまう可能性があるのです。
この記者と数人の同僚は先日，技術的負債とその解決方法に関して話し合った。その議論の要旨は次のようなものだ。この記者の考えでは，技術的負債とは技術上の問題であり，リファクタリングと，そのセーフティネットとしてのテストによる懲罰的アプローチによって解決可能なものだ。これに対して，リファクタリングとテスティングは技術的負債の軽減には必要ではない，十分なものでもない，という反論が一方にある。
前者の論点は次のように要約できるだろう。すなわち，技術的負債を抑えるために，まず穴を掘ることは止めなければならない。その上でシステムのデザインとアーキテクチャは，対象とする実世界の問題の変化にまず追いつき，次いでそれと同じペースを保つために，漸進的にテスト追加とリファクタを行う必要がある。ここでの技術的負債に対する考え方は，それが技術的な問題であり，管理されるべき対象である，従って可能と思われる範囲内に抑えて，継続的に返済をしなければならない，というものだ。Martin Fowler，Ward Cunninqham，(uncle) Bob Martin 各氏を始めとする多くの人々がこのテーマを取り上げ，その重要性と，それが開発チームに対して持つ意味について論じている。
後者の考え方でもこれを否定はしないが，しかしそれは本来の問題のごく一部分であって，外面的症状への対処であり，十分に注意を払わなければ根本原因の解決はできない，と主張する。実際に私たちは，TDD が現れる前からリファクタリングをしてきて，そして "リファクタリング" ということばを作り出した。さらに私たちソフトウェア開発者は，大きなサイクル (分単位ではなく，月あるいは年単位)のリファクタリングとして，システムの再設計や再構築なども行っている。だから TDD とリファクタリングというのは，単なる対処療法でしかない，と言うのだ。そして彼らは Deming 氏のことばを引用する。
これは作業者のランク付けではありません。作業者のパフォーマンスはその属するシステムに大きく左右される，という点には理解が必要です ...
つまりこういうことだ。技術的負債とは，開発者以外の者が負債の所在をほとんど，ときにはまったく認識することができず，そのために負債が制御不可能な量にまでの増大を許容するような環境がシステム - すなわち組織 - の中に構築されてしまうという，より大きな問題の前兆なのである。ゆえにその解決策は，システム，問題の発生過程，コスト透過性などに存在するのであって，開発者に新しいツールセットを与えることではない。
この記者は，これをコミュニティで共有すべき重要な問題であるとして，今回の議論を個人的に要約したいと考えている。