بدهی فنی
بدهی فنی (همچنین به عنوان بدهی طراحی یا بدهی کد شناخته می‌شود) مفهومی در توسعه نرم‌افزار است که نشان دهنده هزینه ضمنی کار اضافی ناشی از انتخاب یک راه حل آسان (محدود) در زمان حال به جای استفاده از یک رویکرد بهتر است که طولانی‌تر خواهد بود.
بدهی فنی را می‌توان با بدهی پولی مقایسه کرد. اگر بدهی فنی بازپرداخت نشود، می‌تواند «بهره» را ایجاد کند، و اجرای آتی تغییرات را سخت‌تر می‌کند. بدهی فنی آنتروپی نرم‌افزار را افزایش می‌دهد. بدهی فنی لزوماً چیز بدی نیست و گاهی اوقات (مانند موارد اثبات مفهوم یا proof-of-concept) بدهی فنی برای پیشبرد پروژه‌ها لازم است. از سوی دیگر، برخی کارشناسان ادعا می‌کنند استعاره «بدهی فنی» تمایل به حداقل رساندن تأثیراتی دارد، که منجر به اولویت بندی کافی در کارهای لازم برای اصلاح آن می‌شود.
با شروع تغییر در یک کدبندی، اغلب نیاز به ایجاد تغییرات هماهنگ به‌طور هم‌زمان در سایر قسمتهای پایه کد یا مستندات وجود دارد. تغییرات مورد نیاز که تکمیل نشده‌اند بدهی در نظر گرفته می‌شوند که باید در مقطعی از آینده پرداخت شود. دقیقاً مانند بدهی مالی، این تغییرات ناتمام باعث روی هم انباشته شده و ساخت یک پروژه را دشوار می‌کند. اگرچه این اصطلاح در توسعه نرم‌افزار به‌طور عمده استفاده می‌شود، اما می‌تواند در سایر حرفه‌ها نیز کاربرد داشته باشد.
دلایل عمده بدهی فنی شامل موارد زیر است: مارتین فاولر در یک پست بلاگ خود چهار نوع بدهی را بر اساس دو دسته متمایز متمایز می‌کند: دسته اول بی پروا در مقابل محتاط، دسته دوم، حساب شده در مقابل ناخواسته.
کنی روبین از دسته‌بندی‌های وضعیت زیر استفاده می‌کند:
«پرداخت بهره» هم به دلیل نگهداری‌های محلی و هم به دلیل عدم نگهداری سایر کاربران پروژه ایجاد می‌شود. توسعه مداوم در پروژه‌های اصلی می‌تواند هزینه پرداخت بدهی فنی را در آینده افزایش دهد.
ایجاد بدهی فنی یکی از دلایل اصلی عدم موفقیت پروژه‌ها در رسیدن به سررسیدهاست. بسیار دشوار است که میزان دقیق کاری که برای پرداخت بدهی که با بروز هر تغییر ایجاد می‌شود را محاسبه کرد.
اگر کار کافی روی پروژه انجام شود تا مانع شکست آن شود، باز هم پروژه‌ای منتشر می‌شود که هنوز هم مقدار قابل توجهی بدهی فنی به همراه دارد. اگر این نرم‌افزار به تولید برسد، خطرات مربوط به اجرای هر گونه ریفکتور آتی برای برطرف کردن بدهی فنی را، به طرز چشمگیری افزایش می‌دهد. در صورتی که قراردادهای تولید نرم‌افزار شامل توافقات سطح خدمات (SLA) باشند، تغییر کد تولید خطر از کارافتادن، خسارات مالی و احتمالاً پیامدهای قانونی را به همراه خواهد داشت. به همین دلیل می‌توانیم تقریباً بدهی فنی به عنوان بدهی را "افزایش داده و شاهد افزایش نرخ بهره باشیم" و تنها زمانی این بدهی کاهش می‌یابد که توسعه محصول متوقف شود.
در حالی که قانون مانی لمن پیش از این اعلام کرده بود که برنامه‌های در حال توسعه به‌طور مداوم بر پیچیدگی و ساختار رو به زوال آنها افزوده می‌شود مگر اینکه برای حفظ آنها کاری انجام شود، وارد کانینگهام در ۱۹۹۲ گزارشی از تجربه مقایسه بین پیچیدگی فنی و بدهی را ترسیم کرد:
جوشوا کریایفسکی در متن خود در سال ۲۰۰۴ با عنوان "Refactoring to" Models، استدلال قابل مقایسه ای را در رابطه با هزینه‌های مرتبط با سهل انگاری در معماری ارائه می‌دهد، که او آن را «بدهی طراحی» توصیف می‌کند.
فعالیتهایی که ممکن است به تعویق افتد شامل مستندسازی، نوشتن تست‌ها، مشخص کردن TODOها و نادیده‌گرفتن هشدارهای تحلیل کد استاتیک و کامپایلر است. موارد دیگر بدهی فنی شامل دانش است که در سازمان به اشتراک گذاشته نمی‌شود و کدهایی که بسیار گیج کننده بوده به راحتی اصلاح نمی‌شود.
جوناد علی با نوشتن مقاله‌ای دربارهٔ توسعه PHP در سال ۲۰۱۴ گفت:
گرادی بوچ مقایسه می‌کند که چگونه شهرهای در حال تحول شبیه به سیستم‌های در حال تحول نرم‌افزاری هستند و چگونه عدم مقاوم‌سازی می‌تواند به بدهی فنی منجر شود.
در نرم‌افزار منبع باز، به تعویق انداختن ارسال تغییرات محلی به پروژه بالادستی نوعی بدهی فنی است.