執行SCRUM-14 –當下解決VS之後解決，效率差24倍
在書中第1次看見這個數字，有點嚇到，尤其自己在寫程式的領域中，遇到程式缺陷時，對於修正所花的時間，並不會很仔細的記錄及計算，所以在看到這個point時，就仔細研讀了一下。書中所提到的是，當工作完成並由測試人員進行整合時，發現到缺陷，是要求立即改正，還是等幾周後，目前工作告一段落，再來改正，那一種花費時間較少呢?
根據統計，幾周後再改是需要花費24倍立即改善的時間，這與缺陷大小、複雜度無關。這個涉及人類大腦限制的問題，因為人腦記憶的事是有上限，而且一次只能集中在一件事情上面。若之後再改，雖然可以累積更多的問題一次解決，但是必須重建思考邏輯架構，並找到當初考量的因素，例如參數的設定、計算的流程、資料庫的設計等等，這些都需要花時間，而且是比立即改正更多的時間。
要知道軟體是一種複雜、多變的產物。雖然我們盡力去降低程式間的複雜度、減少變化的模式，但是在整個專案未完成前，軟體都是持續發展，甚至是多人協作。缺陷發現的當下未解決，可能被後續其他的變數、功能所牽連，造成日後修正的範圍更為擴大、更為複雜。而這個數據雖然不需要盡信之，但告訴我們，缺陷在發現時立即改善，否則你會付出更大的代價。