Tina總容易讓我氣急敗壞，她已經不止一次的指出了在我的程序中所出現的錯誤，有的屬於代碼級的Bug，而有的則是設計上的問題。在她面前我總試圖以經驗豐富的大拿自居，因爲我時常可以在她的幼稚的代碼中發覺顯見的錯誤，嗅到潛在的錯誤。可我又時常被她搞得灰頭土臉，一個菜鳥也可以令大拿啞口無言，實在是很能說明問題的。最近燥熱的天氣很容易讓人動火，還好她是女士，否則我怕我真的會出言不遜的。當然，我至今還沒有犯過這樣一時失控的錯誤，還保留着一點大拿們一般所要具備的“謙遜”的氣質，證明自己還算半個大拿——一個技術不過硬但品行還湊合的大拿。
當冷靜下來開始仔細考慮這些錯誤時，我發現很多問題都可以歸結到一個更爲本質的問題上來。在我做出設計決策和隨後的代碼實施的過程中，不少地方都存在草率的痕跡。沒有反覆推敲就下了決定，以致這個系統在很多地方缺乏自圓其說的能力，有些功能甚至是自相矛盾的。我奇怪自己爲什麼會犯這樣的錯誤，也許是太輕視這個任務了（我對ASP項目一向都有一點不屑），也許自己還未完全理解需求。
不過說到需求，我到是可以有所推卸，因爲我相信，Tina和我還有其他人都沒有真正徹底的搞懂過這個任務裏的所有需求。我們總是認爲，至少應該等有一個可供評估的Prototype出現，一些問題纔可以澄清，需求才會逐漸變得明晰起來。我想這一點應該是正確無疑的，這種作法尤其適合小型系統的快速開發。
但是，我的漫不經心和自以爲是，還是讓我爲此付出了代價，雖然不影響大局，但至少讓我失去了作爲大拿的沾沾自喜。問題在於，當Prototype成形後，我對它所作的改動卻是缺乏思量的。由於，沒有足夠的思想準備，在一個系統缺乏統一的若干約定、規則的前提下，我就開始憑藉以往的經驗，對之進行了隨心所欲的改動，而這些改動卻引入了新的約定和規則，不同於前次的約定和規則，這就是那些問題的始作俑者，另我大失掩面的根源所在，而這一切卻被“聰明”的Tina給抓住了。
關於系統內規則和約定的不統一，我記得Frederick Brooks在他的《The Mythical Man-month》一書中涉及“外科手術隊伍”時曾經有所提及，不過那裏的混亂是由於存在對系統具有同等主導力量的多個專家而導致的。從效果來看，我似乎在扮演多人角色，多個不同風格的“專家”。
Prototype形成之前的草率設計＋Prototype形成之後的草率修改＝我的在Tina面前的灰頭土臉
這就是我從這一事件中總結出來的公式。
