GitHub 在其資源文章中介紹「技術債」的概念，指團隊為了加快交付速度而選擇次佳做法，所留下來未來必須償還的隱藏成本。技術債可能是刻意承擔的策略性選擇，也可能是因需求不明、經驗不足或遺留系統整合等原因意外產生，兩者都會隨時間累積，增加維護與修改程式碼的難度。
文章把技術債分成十二種類型，包括架構債、建置債、程式碼債、缺陷債、設計債、文件債、基礎設施債、人力債、流程債、需求債、服務債與測試自動化債，涵蓋軟體開發生命週期的各個環節。要掌握技術債規模，可以透過程式碼審查、靜態分析工具、測試覆蓋率指標、文件盤點與部署稽核等方式，找出哪些環節的技術債已經累積到需要處理的程度。
技術債若長期不處理，會讓程式碼品質下滑、維護成本上升、安全漏洞風險增加，甚至影響團隊招募與留才，因為沒有人想長期在混亂的程式碼基礎上工作，新功能上市的時間也會因此拉長。這也是為什麼越來越多開發團隊會把技術債管理視為日常工作的一部分，而不是等到問題爆發才處理。
對正在學程式的孩子來說，技術債這個概念提醒大家：寫程式不只是讓程式能跑起來，還要考慮以後好不好維護、好不好修改。養成定期重構、寫測試、留下清楚文件的習慣，就是從小培養良好程式習慣的開始，長期下來能避免累積難以收拾的爛攤子。
軟體工程程式維護開發流程程式教育