軟體開發專案中常見的爭論，在於花時間改善軟體品質，還是專注於發布更有價值的功能。通常交付功能的壓力主導了討論，導致許多開發人員抱怨他們沒有時間處理架構和程式碼品質。這場爭論基於一個假設，即提高品質也會增加成本，這是我們共同的經驗。但反直覺的事實是，內部軟體品質消除了減緩開發新功能的負擔，從而降低了軟體增強的成本。

程式碼異味是一種表面現象，通常對應於系統中更深層的問題。這個術語最初是由 Kent Beck 在協助我撰寫重構一書時提出的。

在每個正常規模的團隊中，將任何類別技術的替代方案選擇限制為三個。這些是：當前的合理預設值、我們正在試驗的試驗值，以及我們討厭並想退休的值。

在DesignStaminaHypothesis中，設計回報線是指可以權衡設計品質和上市時間的功能量。

設計良好的軟體是否值得花費心力？

（這是您字典中的新增項目。）

令人厭惡（形容詞）：無法測試的軟體。

技術負債是一個非常有用的概念，但它引發了一個問題：您要如何衡量它？遺憾的是，技術負債不像財務負債，因此很難看出您負債的程度（儘管我們最近似乎在衡量財務負債方面遇到了一些問題）。

軟體系統容易累積廢棄物 - 內部品質的缺陷，使得修改和進一步擴充系統比理想情況更困難。技術負債是一個比喻，由 Ward Cunningham 提出，說明如何思考處理這些廢棄物，並將其視為財務負債。新增新功能所需的額外工作量就是支付債務的利息。

在過去幾個月中，有幾篇文章關於技術負債，提出了哪些類型的設計缺陷應該或不應該歸類為技術負債的問題。