技術的負債(Technical dept) は Ward Cunningham 氏の造語で，次のようなことだ。
もうひとつ，もっと重大な落とし穴があります。整理統合に関する失敗です。未熟なコードでも正しく動作さえするなら，顧客には問題なく受け入れてもらえるかも知れません。しかしそれが大量になるとプログラムが理解不可能になり，対応可能なプログラマが極めて限定されてしまうため，最終的には柔軟性に欠ける製品になってしまいます。コードを初めて出荷したときに負債が始まります。多少の書き直しですぐ返済できる程度の負債なら，開発速度を速めてくれますし，トランザクションのコストも成果としてのプログラムによって相殺されます。危険性が発生するのは，債務が返済不可能な場合です。適切でないコードのために費やされる時間はすべて，その負債に対する利子に数えられます。整合性の取れていない実装の負債が重荷となって，開発組織全体が立ち往生してしまうようなことさえあり得るのです。実装がオブジェクト指向かどうかは問題ではありません。
LinkedIn Agile Alliance グループでは，今日のグローバルなソフトウェア開発の世界において，"技術的負債" が現在もメタファとして有効なのか が議論されている。この議論を立ち上げた Marvin Toll 氏によれば，
およそ 20 年が経過したことで私たちは，このメタファが現在も有効であるかを見極めるのに十分な経験を積んだと思います。私の意見ですか？ "有効ではない" です。英語を第２言語としてますますグローバル化する IT コミュニティにおいて，そして 140 文字(twitter の発言長)という集中力の限界において，このメタファはもはやアプリケーション開発を適切に表現するものではありません。
別の言い方をするなら，低品質のコードにまつわる議論は，財務的ユースケースについて説明する時点ですでに行き詰っているのです。
見過ごされがちだが重要な問題に気付かせる手段として，この用語とその重要性を守ろうと，多数の人々が議論に参加した。Daniel Nelson 氏は，人々がこの用語をよく理解していないことに危険性を感じている，と述べている。
私のプログラミング経験，ビジネス分析の経験，そして現在の CSPO (認定スクラムプロダクトオーナ) としての経験から言うならば，アジャイルチームのメンバが技術的負債 (あなたの周りでは違う呼び方をしているかも知れませんが) に関する基礎的知識のみならず，さらに一般的な原因や対象法について知らないのは危険だと思います。
技術的負債は，それを防止するための明確な努力がなければ，ソフトウェア自体を損なうほど制御不能に成長し得るものなのです。コードはバギーで断片的になり，インターフェースは支離滅裂になります。
私はここで使ったすべてのメタファを気に入っていますし，この問題にチームが注意を払うために使われる限り，その適用のすべてが適切なものだと思っています。
Steve Gordon 氏は，メタファが共存可能であることを指摘する。
メタファは単なるモデルですが，数学的用語や図示規則の代わりとして，一般的な概念を使用します。すべてのモデルがそうであるように，メタファもある側面を捉えてはいますが，無視されている面もあります。
技術的負債というメタファは，悪いコードによるコスト増大について説明するものであって，悪いコードとは何かを説明するものではありません ... 複数のモデルあるいはメタファは，特にそれらが異なる側面を表現するものであるか，あるいは違う人々にとって理解しやすいものであるならば，互いに干渉することなく共存できるのです。
そして QA マネージャの Curtis Stuehrenberg 氏は，技術的負債が自身の役割において重要な用語である理由について説明している。
私は個人的に，この用語が気に入っています。技術的負債についての議論には，一般的なプロジェクトチームでは通常うやむやにされてしまうような問題点，あるいは論点の重要性を高める傾向があるからです。どのような種類のチームに所属しているのであれ，自分自身のために必要な基盤的作業と，営業チームが実績を上げるためのピカピカ派手な行動との間には，いつでも緊張関係が存在します。増改築の見本市 (home improvement show) を例に取るなら，その緊張感はちょうど，転売前の家を磨き直そうとしている住宅転売業者 (house flipper) に似ています。家が一日ごとに市場価値を落としていくことは，その直接的な維持費に加えて，他に投資した場合に基づく機会費用の面においても転売業者の懐を痛めます。ですから転売業者は，できる限り短い時間でプロジェクトを実施したいと思うようになります。同時に ROI を最大化するために，資産投資も最小にしたいと考えます。
ベテランの転売業者たちを詳しく観察すれば，彼らが壁を開けたり，床下に潜ったりするようなことを避けるための努力を惜しまない，ということに気付くはずです。経験豊富な彼らは，そんなことをしたら最後，構造的あるいは安全上の理由で補修の必要な問題が見つかって，そうしなければ将来の顧客に対してそのような危険の事実を開示する法的義務を負う，ということをよく知っているのです。
プロジェクトにおける技術的負債は，私たちが転売目的で購入しようとする家の壁裏や床板の下，屋根の中に潜んでいます。ほとんどのチームが，元々のソースコードの解読を避けるための努力を惜しまないでしょう。それをすればたちまち，膨大な手直し作業の蓋を開けてしまうことになるからです。そして家の場合と同じように，古いコードベースほどノブとチューブによる配線 (旧式の電気配線) やアスベスト，鉛の入った塗装などが見つかる可能性が高いのです。
そんな理由から，私はQA担当として "技術的負債" の話をするのが好きなのです。もし私たちが外に出て，天窓の周りにあるに違いない黒カビをどうしてもチェックしたい，と言ったなら，私たちはリスクを合理的に測定して，受け入れ可能なリスク軽減対策を選択することができるようになります。それを話題にしないということは，背中に巨大な標的を縫い付けた新しいTシャツを誰かが着る，ということを意味するのです。
では，技術的負債というのはよいメタファなのだろうか？何の害も及ぼさないものである以上，ほとんどの人々にとってはまだ有効なのだろう。すべての文化やチームにとって適切なものではないのかも知れないし，メタファの共存性ゆえに受け入れられるものなのかも知れない。あなた自身の経験とは一致しているだろうか？