這點也和我自己的經驗不謀而合。在專案的規劃中，我們都把需求(Requirement), 設計(Design)和建構(Construction)分開成為一個循序的過程。設計過程是確保你可以建構出符合需求的working software/component。但是在真實的情況下，我所經歷的設計過程其實是一些不同的Activities不停的來回，而且沒有一定的順序。譬如說：
- 首先要了解需求，開始設計。
- 如果設計發現有定義模糊的需求，要進一步和stakeholder釐清。
- 為了要確保設計是可行的，也須需要做POC(Proof of Concept)。
- 魔鬼都在細節中。所以POC也不能馬虎，幾乎就是要做到Production品質的Code。
- 如果POC發現問題，要回頭修正設計。
- 如果POC發現其他Dependency的元件的問題，也要回頭在設計中考慮workaround。
- 如果設計怎麼調整都沒有辦法解決，又要回頭修正需求/規格。
- 甚至設計也有可能會發現需求/規格從未考慮過的事情，必須回頭和stakeholder反應。
- 需求會中途改變，要重新修正設計，同時又要做POC。
- ...
這一切的活動幾乎不會有停下來的一天，不過這個過程會逐漸收斂（當然也有可能不會收斂，那可能是某種大災難的指標。）。最終確保我可以建構出符合需求的程式碼，這個過程中也有個副產品，就是程式碼本身。
就譬如設計一台太空梭，為了要驗證太空梭的設計藍圖，團隊就必須打造出一台太空梭來通過各式各樣的測試。團隊可能先做出第一版的太空梭，發現一些問題，在重頭修正，打造第二版的太空梭，不停的重複這個過程，直到打造出大家都有信心把太空人送上天的太空梭。
這真的很難區分工程師到底是在建造還是在設計。很有可能在動手做的過程中，卻啟發了他可以改善設計元素。這就是真實世界的情況。
回到Jack的文章，對我來說Jack就只是希望軟體業界能夠承認這個事實，"Source code is the design."。基於這個事實，我們可能需要一些討論來看"需求, 設計, 建構"這樣的模型，到底適不適合用來詮釋軟體開發的過程。
P.S. 其實軟體專案開發過程中還有品質控管(Quality Control)的階段，為了方便說明，在此簡化了這個部分。
