Bug也是累積的。你的bug越多，消除每一個bug也就越不容易。一定程度上是因為bug互相影響，表現出來的失敗可能是很多錯誤共同的結果—這就導致很難找到每一個錯誤。這也是心理上的，當有很多bug的時候，人們自然就缺少激情去找到并解決這些bug—這是一種在《Pragmatic Programmer》一書中被稱為“破窗效應”的現象。破窗效應（英語：Broken windows theory）是犯罪學的一個理論，該理論由詹姆士·威爾遜（James Q. Wilson）及喬治·凱林（George L. Kelling）提出。此理論認為環境中的不良現象如果被放任存在，會誘使人們仿效，甚至變本加厲。一幢有少許破窗的建筑為例，如果那些窗不被修理好，可能將會有破壞者破壞更多的窗戶。破窗理論能夠很好地解釋人們違反代碼整潔之道，對質量問題視若罔聞的背后原因：是因為原來就是垃圾，別人做了錯誤的行為沒有受到懲罰或者約束，那么我做同樣的事情和行為也是正常的，大家都一樣。但是所謂的沒有關系的錯誤或者瑕疵被放過去，累積起來，等雪崩的時候，沒有一片雪花是無辜的。最后整個團隊為質量買單。怎么避免破窗效應？讓我們的質量能夠保持在一個健康的狀態呢？應對方式就是童子軍軍規：“當你離開一個露宿營地的時候，一定要讓它比你來的時候更整潔干凈一點?！蔽覀兊拿看翁峤欢紤撟尨a比前一個版本更干凈一點，哪怕是減少一部分重復代碼，修正一個格式問題。這樣也能讓我們遠離代碼的壞味道，保持我們代碼和架構的整潔。
這些優點將會是質量的有力保障。驗收測試驅動開發（ATDD）：在代碼層次，在編碼之前寫測試腳本就是上面所說的TDD，而在業務層次，在需求分析時就確定需求（如用戶故事）的驗收標準，就是這里所說的驗收測試驅動開發（Acceptance Test Driven Development，ATDD）。TDD和ATDD的關系如下圖所示。ATDD解決了TDD在實踐中遭遇的一部分實際障礙：比如工期緊張然而單元測試需要的時間又比較多等。從需求的角度去準備驗收標準和測試用例。同樣可以保障從開發的開始就有較高的質量。行為驅動開發（BDD）：BDD可以看成ATDD的延伸，只是BDD更強調用戶的視角、用戶的行為，為ATDD注入了“Given，When，Then”這樣特定的需求描述語言。和敏捷的user story極為吻合。TDD在寫測試用例時，常常會提出“我們應該先測什么”，然后針對測試的條件來填充代碼，而BDD則試圖換一種方式去思考問題，即問自己“預期的行為是什么？”，可能會寫出結構更好的代碼。說到底，BDD更關注客戶的需求，通過了解客戶的不同行為，對客戶的需求有更深刻的理解，從而借助對需求逐漸深入的理解來驅動軟件開發。下圖就是一個BDD的典型case：而BDD和TDD的關系則可以通過下圖清晰的看出來區別所在：
