Q48: 分析的結果必須反應確切的問題敘述以及可能解決方案的限制，但不一定有作用。

Rebecca Wirfs-Brock: "Analysis results need to reflect an accurate statement of the problem and constrain possible solution, but they don't have to work." 分析是在反應使用者的真實世界，而設計必定會反應實作者的世界，兩者並不一定完全一致，因為設計者仍然必須解決一些實作的問題，因此實作時會加上一些條件，這種現象十分普遍，解決之道可能可以使用敏捷方法或MDA技術，甚至CRC cards技術，因為非正規的發展流程允許參與者提供設計意見而無障礙。

Q47： 如果你能衡量而能用數據表達你所說的，就表示你知道你在說甚麼，否則你的知識是貧乏而且不完整。

這是原自於Lord Kelvin (1883)所說的話："When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knoledage is of a meager and unsatisfactory kind."這則諺語是『軟體度量』的基本之一。

Q46：除非即刻需要而且有意義否則就不要產生文件。

這是所謂Martin's First Law of Documentation，這個規則係來自「敏捷宣言」第二項:『可用的軟體重於詳盡的文件』，這並非叫你不要寫文件，但太多太詳盡的文件不如少一點，發展團隊撰寫與保養的是簡短合理且有結構的文件，這就是Martin的第一文件規則。

Q45：大致對比嚴格錯來得好。

來自 "It is better to be roughly right than precisely wrong." (John Maynard Keynes 英國經濟學家 1883-1946)，這是在呼應Q44諺語。

Q44: 開發沒有終點。只有釋出 (release)。

對於多數的軟體開發，不斷的功能延伸、錯誤修補是很常見的。如果要等到完全的開發完畢才做系統的發佈，恐怕永遠沒有上線的一天。

所以階段性的版本釋出計畫是很重要的。相繼而來的錯誤追蹤管理也很重要。

Q43: 如果你想毀掉一個人的一天，就給他一個程式; 如果你想毀掉一個人的一生，就教他寫程式

If you give someone a program, you will frustrate them for a day;  if you teach them how to program, you will frustrate them for a lifetime.

Q42 反覆發展法僅適用在你希望能成功的軟體專案

You should use iterative development only on projects that you want to succeed. - Martin Fowler

『反覆與漸增』(iteative and incremental)是大部份近代軟體發展法的核心，如UP，XP，SCRUM等，這是大家都懂，但卻不容易做到的觀念，何謂反覆發展(iterative development)?就是『接受改變』(embrace change)(Beck2000)。我曾翻看去年幾篇部落格文章，諸如"千奇百怪的需求"、"好人難為"、"早點來"等，內容都談到發展者對客戶或老闆的需求改變，心裡十分痛苦，我也曾在相關的意見箱哩，說這種現象並不希奇，問題是你要用何種發展方法來應付這種『自然現象』，Agile methods，MDA，或者遵守一些設計原則，如OCP，DIP ...，或者一些設計樣式(design patterns)！我看都可以， 不過不管用何種方法，就如Martin Fowler所講，『反覆與漸增發展方法』應該是核心所在。