コードベース上で変更が開始されると、コードベースの他の部分やドキュメントにも、他の協調的な変更が必要になることがよくある。必要とされているものの完了していない変更は負債とみなされ、支払われるまでは利息が上乗せされて発生するため、プロジェクトの構築が煩雑・厄介になる。この用語は主にソフトウェア開発で使われるが、他の専門的職業にも適用できる。
原因.
技術的負債の一般的な原因は次のとおり。
技術的負債の処理または返済.
ケニー・ルービンは、次のような状態区分を用いている。
結果.
「利子の支払い」は、ローカルで必要なメンテナンスと、プロジェクトの他のユーザーがメンテナンスを行わないことの両方によって発生する。上流のプロジェクトで継続的な開発を行うと、将来的に「負債を返済する」ためのコストが増加する。完結していない作業を完了させるだけで、負債を返済することになる。
技術的負債の蓄積は、プロジェクトが納期に間に合わなくなる大きな原因となる。技術的負債を返済するために必要な作業量を正確に見積もることは困難である。変更に着手するたびに、不確実な量の未完成の作業がプロジェクトにコミットされる。プロジェクトは、未完了の作業（負債）が完了するための時間よりも多いことに気付いたときに、期限を逃してしまう。予測可能なリリーススケジュールを実現するためには、開発チームは未完成の作業（または負債）の量を常に小さくするために、進行中の作業の量を制限する必要がある。
“進化するプログラムが継続的に変更されると、構造の劣化を反映して複雑さが増し、それを維持したり減らしたりする作業が行われない限り、複雑さが増していく。”
“この技術的負債を返済しないことの代償は明らかである。最終的には、機能を提供するためのコストが非常に遅くなり、設計の良い競合ソフトウェア製品が機能面で設計の悪いソフトウェアを追い越すことが容易になる。私の経験では、設計の悪いソフトウェアは、エンジニアのストレスを増大させ、スタッフの離職率を高める（これは、機能を提供する際のコストと生産性に影響する）。さらに、コードベースが複雑になると、作業を正確に見積もることができなくなる。また、開発会社が機能ごとに料金を設定している場合、コードを納品する際の利益率が低下してしまう。”