مفهوم بدهی فنی نخستین بار توسط کانینگهام مطرح شد. وی بدهی فنی را اینگونه تعریف کرد: وقتی کدی را برای اولین بار تحویل می‌دهید مثل این است که خود را بدهکار کرده باشید. هر بدهی کوچک باعث افزایش سرعت توسعه می‌شود به شرطی که آن را در اسرع وقت و با بازنویسی کد، بازپرداخت کنید. زمانی این موضوع خطرناک می‌شود که بدهی بازپرداخت نشود. هر دقیقه‌ای که از عمر این کد که کاملا درست نوشته نشده است می‌گذرد، مانند بهره‌ای است که به بدهی قبلی افزوده می‌شود. شرکت‌های مهندسی زیر فشار بدهی ناشی از بی‌توجهی به اینگونه پیاده‌سازی‌های بازنویسی نشده ممکن است زمین‌گیر شوند و پیشرفت آنها متوقف شود.
کانینگهام برای این که به تیم کسب‌وکار خود نشان دهد ساخت سریع نرم‌افزار برای دریافت بازخورد روش خوبی است، از استعاره‌ی بدهی فنی استفاده کرد. برای این کار، وی بر دو نکته‌ی کلیدی تأکید کرده است: اول آن که تیم و سازمان باید با افزایش درک و شناخت خود از حوزه‌ی کسب‌وکار، مراقب بازپرداخت بدهی‌ها باشد و دوم آن که با افزایش شناخت تیم و برای استفاده از آموخته‌های جدید، طراحی و پیاده‌سازی سیستم باید تغییر کند و تکمیل گردد.
از زمان معرفی این واژه در اوایل دهه‌ی 1990، صنعت نرم‌افزار برداشت‌های آزادی از تعریف کانینگهام داشته است. امروزه بدهی فنی، هم به میانبرهایی که آگاهانه و عامدانه انتخاب می‌شوند و هم به موضوعات نادرستی که به سیستم نرم‌افزاری آسیب می‌زنند گفته می‌شود. این موضوعات شامل موارد زیر هستند:
کانینگهام قصد نداشت که با «بدهی فنی» به نبود بلوغ در تیم و کسب‌وکار یا کاستی‌های فرایند اشاره کند و آن را دلیل بی‌نظمی در طراحی، استفاده از تجربه‌های ضعیفِ مهندسی و کمبود آزمون‌ها بداند. این نوع از بدهی‌ها را می‌توان با آموزش صحیح، درک روش درست به کارگیری تجربه‌های فنی و تصمیم‌گیری‌های منطقی در کسب‌وکار رفع نمود. به دلیل ماهیت غیر مسئولانه و غالباً تصادفیِ ایجاد این گونه از بدهی، آن را «بدهی ناشی از بی‌تجربگی» یا به اختصار «بدهی بی تجربگی» می‌نامیم. این بدهی با نام‌های دیگری مانند بدهیِ بی‌دقتی، بدهی غیرارادی و زباله نیز شناخته می‌شود.
علاوه بر این، نوع دیگری از بدهی به نام «بدهی فنی اجتناب‌ناپذیر» نیز وجود دارد که معمولا غیر قابل پیش‌بینی و غیرقابل پیشگیری است. برای نمونه، شناخت ما از «طراحی خوب» در ابتدا کاملاً مشخص نیست و پس از پیاده‌سازی ویژگی‌های باارزش برای کاربران و مبتنی بر طراحی انجام شده، تازه به میزان خوب یا بد بودن طراحی پی می‌بریم. نمی‌توانیم مسیر تکامل و تغییر محصول و طراحی آن را به صورت کامل، از پیش و در ابتدا پیش‌بینی کنیم. بنابراین ممکن است تصمیم‌های طراحی و پیاده‌سازی که زود گرفته شده‌اند با بسته شدن حلقه‌های مهم یادگیری و کسب یادگیری معتبر نیاز به تغییر داشته باشند.
تغییرات ایجاد شده در بخش‌های که تحت تأثیر قرار گرفته‌اند در دسته‌ی بدهی‌های فنی اجتناب‌ناپذیر قرار می‌گیرند.
به عنوان نمونه‌ای دیگر فرض کنید مؤلفه‌ی شرکت ثالثی را خریداری کرده‌ایم و از آن در محصول استفاده کرده‌ایم. به مرور زمان رابطه‌های این مؤلفه تغییر کرده‌اند و کامل‌تر شده‌اند. محصول ما که زمانی به خوبی با این مؤلفه کار می‌کرد دچار نوعی بدهی فنی می‌شود که ما مقصر آن نیستیم. اگرچه این بدهی ممکن است قابل پیش‌بینی باشد( این که سازنده‌ی مؤلفه، رابطه‌های آن را به مرور تغییر خواهد داد، خیلی هم دور از ذهن نیست)، اما قابل پیشگیری نیست زیرا نمی‌توانیم پیش‌بینی کنیم که توسعه‌دهندگان مؤلفه چگونه آن را در آینده تغییر خواهند داد.
آخرین نوع بدهی‌فنی، «بدهی‌فنی استراتژیک» است. این نوع بدهی ابزاری است که می‌تواند به بهبود اندازه گیری‌های کمّی و استفاده از مباحث اقتصادی در تصمیم‌گیری‌های مهم و فوری کمک کند. برای نمونه، شرکتی آگاهانه و عمداً تصمیم استراتژیکی می‌گیرد که میان‌بری را در توسعه محصول انتخاب کند تا به یکی از اهداف مهم و کوتاه‌مدت خود دست یابد. به عنوان نمونه‌ای از این اهداف می‌توان به عرضه پیش از موعدِ محصولی به بازار اشاره کرد که زمان عرضه‌ی آن بسیار حساس است و اهمیت فوق‌العاده‌ای دارد. در سازمانی که سرمایه‌ی محدودی دارد و با خطر اتمام منابع مالی قبل از تکمیل محصول مواجه است، تنها راه جلوگیری از نابودی سازمان، عرضه محصول با وجود بدهی‌فنی به بازار است. در ابتدا از هزینه‌ی توسعه چنین محصولی کاسته می‌شود تا سازمان پس از کسب درآمد بتواند به توسعه‌ای مداوم و خودکفا دست یابد.
صرف نظر از چگونگی افزایش بدهی‌فنی، این اصطلاع، استعاره‌ی بسیار مؤثری است، زیرا آگاهی افراد را افزایش می‌دهد و دید آنها را نسبت به موضوع مهمی باز می‌کند. این استعاره در ذهن افراد حوزه‌ی کسب و کار که علاقه‌ی زیادی به کسب مهارت در زمینه‌ی وام و بدهی‌های مالی دارند، به خوبی جا می‌افتد. زمانی که آنها اصطلاح بدهی‌فنی را می‌شنوند، بی‌درنگ تأیید می‌کنند که لازمه‌ی بدهی، پرداخت بهره است و این بهره، خود را به شکل کارهایی نشان می‌دهد که در آینده به کارهای توسعه اضافه می‌شود. وقتی که بدهکاریم، دوگزینه پیش روی ماست: می‌توانیم کماکان به پرداخت بهره ادامه دهیم (با پرداختن به حواشی مشکلات) یا اینکه اصل بدهی را پرداخت کنیم (مثلاً کد را بازسازی کنیم تا قبل از تغییر بعدی، تمیزتر و ساه شود).
کنی اس. روبین
