بدهی فنی

بدهی فنی (همچنین به عنوان بدهی طراحی  یا بدهی کد شناخته می شود) مفهومی در توسعه نرم‌افزار است که نشان دهنده هزینه ضمنی کار اضافی ناشی از انتخاب یک راه حل آسان (محدود) در زمان حال به جای استفاده از یک رویکرد بهتر است که طولانی‌تر خواهد بود.  
بدهی فنی را می توان با بدهی پولی مقایسه کرد.  اگر بدهی فنی بازپرداخت نشود، می تواند "بهره" را ایجاد کند، و اجرای آتی تغییرات را سخت تر می کند. بدهی فنی آنتروپی نرم‌افزار را افزایش می دهد. بدهی فنی لزوماً چیز بدی نیست و گاهی اوقات (مانند موارد اثبات مفهوم یا proof-of-concept) بدهی فنی برای پیشبرد پروژه ها لازم است. از سوی دیگر، برخی کارشناسان ادعا می کنند استعاره "بدهی فنی" تمایل به حداقل رساندن تأثیراتی دارد، که منجر به اولویت بندی کافی در کارهای لازم برای اصلاح آن می‌شود.   
با شروع تغییر در یک کدبندی، اغلب نیاز به ایجاد تغییرات هماهنگ به طور هم زمان در سایر قسمتهای پایه کد یا مستندات وجود دارد. تغییرات مورد نیاز که تکمیل نشده اند بدهی در نظر گرفته می شوند که باید در مقطعی از آینده پرداخت شود. دقیقاً مانند بدهی مالی ، این تغییرات ناتمام باعث روی هم انباشته شده و ساخت یک پروژه را دشوار می کند. اگرچه این اصطلاح در توسعه نرم‌افزار بطور عمده استفاده می شود ، اما می تواند در سایر حرفه ها نیز کاربرد داشته باشد.

عواقب

"پرداخت بهره" هم به دلیل نگهداری‌های محلی و هم به دلیل عدم نگهداری سایر کاربران پروژه ایجاد می شود. توسعه مداوم در پروژه‌های اصلی می‌تواند هزینه پرداخت بدهی فنی را در آینده افزایش دهد.
ایجاد بدهی فنی یکی از دلایل اصلی عدم موفقیت پروژه‌ها در رسیدن به سررسیدهاست. بسیار دشوار است که میزان دقیق کاری که برای پرداخت بدهی که با بروز هر تغییر ایجاد می‌شود را محاسبه کرد. 
اگر کار کافی روی پروژه انجام شود تا مانع شکست آن شود، باز هم پروژه‌ای منتشر می‌شود که هنوز هم مقدار قابل توجهی بدهی فنی به همراه دارد. اگر این نرم‌افزار به تولید برسد، خطرات مربوط به اجرای هر گونه ریفکتور آتی برای برطرف کردن بدهی فنی را، به طرز چشمگیری افزایش می‌دهد. در صورتی که قراردادهای تولید نرم‌افزار شامل توافقات سطح خدمات (SLA) باشند ، تغییر کد تولید خطر از کارافتادن، خسارات مالی و احتمالاً پیامدهای قانونی را به همراه خواهد داشت. به همین دلیل می‌توانیم تقریباً بدهی فنی به عنوان بدهی را افزایش داده و شاهد افزایش نرخ بهره باشیم و تنها زمانی این بدهی کاهش می‌یابد که توسعه محصول متوقف شود. 
در حالی که قانون مانی لمن پیش از این اعلام کرده بود که برنامه‌های در حال توسعه به طور مداوم بر پیچیدگی و ساختار رو به زوال آنها افزوده می شود مگر اینکه برای حفظ آنها کاری انجام شود ، WARD Cunningham در ۱۹۹۲ گزارشی از تجربه مقایسه بین پیچیدگی فنی و بدهی را ترسیم کرد: 
جوشوا کریایفسکی در متن خود در سال 2004 با عنوان Refactoring to Models ، استدلال قابل مقایسه ای را در رابطه با هزینه های مرتبط با سهل انگاری در معماری ارائه می‌دهد ، که او آن را "بدهی طراحی" توصیف می کند.  
فعالیتهایی که ممکن است به تعویق افتد شامل مستندسازی، نوشتن تست‌ها ، مشخص کردن TODO ها و نادیده‌گرفتن هشدارهای تحلیل کد استاتیک و کامپایلر است. موارد دیگر بدهی فنی شامل دانش است که در سازمان به اشتراک گذاشته نمی‌شود و کدهایی که بسیار گیج کننده بوده به راحتی اصلاح نمی‌شود. 
جوناد علی با نوشتن مقاله‌ای درباره توسعه PHP در سال 2014 گفت: 
گرادی بوچ مقایسه می‌کند که چگونه شهرهای در حال تحول شبیه به سیستم‌های در حال تحول نرم‌افزاری هستند و چگونه عدم مقاوم سازی می تواند به بدهی فنی منجر شود. 
در نرم‌افزار منبع باز، به تعویق انداختن ارسال تغییرات محلی به پروژه بالادستی نوعی بدهی فنی است.