多年以來，軟體行業一直在使用一種類比，即以建築行業來做參考和比喻。這種比較在軟體語言裡隨處可見，比如架構（architecture）、地基（foundation）、建造者（constructor）、專案（project）、施工規範（building code）等。這些說法是如此之流行，以至於影響到了我們對軟體開發的理解。不幸的是，這種比喻從根本上來說是不恰當的，它的缺陷已經把我們引向了一些錯誤的道路。
在建築行業，很多重點都放在可預測性上——預先把需求確定清楚，並且縮減成本。這些都是成熟行業的標誌。而當我們把這些重點應用到軟體上時，問題就來了！
經驗法則、施工規範和原材料
現代建築可以追根溯源到幾百甚至幾千年以前——就看你把起點放在哪兒。經過所有歷史的沉澱，大量的專業知識凝結在了經驗法則裡，比如：
- 在大部分地方，每平方英尺的建築成本是一個眾人皆知的常數。舉個例子，我們最近在家裡做了一些翻修，行業裡的朋友就提醒我們說：在渥太華，典型的翻修成本在每平方英尺$35到$50之間。他們說得非常準！
- 對水泥樓板深度的一個比較好的評估是，相當於它的無支周長的1/180。
另一方面，軟體最多也就70年的歷史。它的經驗法則還沒有像建築那般牢靠的歷史，尚不足以保障堅不可摧的應用。
經驗法則最終會被編寫成施工規範而固化下來。造房子的時候，施工規範決定了從壁骨間距，到牆上和屋頂絕緣物數量的方方面面。這些規範意味著所有的房子都達到了最低要求標準，極大地提升了成本的可預測性。
這些施工規範的存在，主要是因為建築材料（木頭、鋼鐵等）和工具（鐵錘、鋸子等）的種類是有限的。這些材料的屬性和故障模型都是可預見的。能與特定材料配合使用的工具為數不多，也已被充分認知。當然，在建築行業，材料和工具也在持續進化，但其進化速度遠遠比不上軟體。
在軟體行業，跟上一系列新材料和工具的難度要大得多！程式語言、程式庫、支援工具每年都會冒出來，並且不斷進化。內容也在不斷豐富。即使我們專注於現有的語言和庫，為了制定標準規範而去探索所有的細節並且體會個中的細微差別，這也需要花上幾年的功夫。
正是因為易懂、穩定的材料和工具，才有了制定建築規範的可能。而軟體世界的不穩定性，決定了我們在這個領域永遠也不會有“施工規範”。
在軟體行業不存在有用的經驗法則或施工規範！
物理約束和穩定的需求
大樓、橋樑和其他建築工事都受著物理約束的支配。依據使用的材料，這些約束決定了一個建築物的尺寸、形狀和用途。舉例來說，木結構建築受限於4~6層的高度；橋樑的跨度受限於使用的材料，以及這些材料相關的物理屬性。
大樓和橋樑的建築代表了一個問題域，已被人世代研究和試驗。因此，客戶需要問的問題都是可預見的，答案的範圍也是有約束的。
建築設計必須適應現場和功能的約束。想象一下，把辦公樓建成圍繞單點旋轉的陀螺儀那樣，儘管很有趣，但它在物理上不切實際，也無法滿足功能上的需求。在修築橋樑或公路時，依據需要承受的車輛型別和尺寸，都有清晰的標準去遵循。
而軟體並不受制於類似的約束。如果客戶真的想要一個陀螺儀那樣的東西，我們很可能可以交付。我們需要支援的使用者型別以及用途，與建築比起來要寬泛得多！
大樓一旦開建，地基都打好了，你就不能輕易改變尺寸或現場位置。大樓的內部機構一旦開工建設，你就不能隨意決定新增一個電梯井或者加一個側翼。修建橋樑時，一旦橋墩澆築好了，你就不能因為客戶選錯了地方而把它們移動20米。（好吧，你能，只不過在此之前的工作都白費了，你需要從頭再來！）
而對於軟體來說，我們幾乎可以做我們想要的任何改動，簡單也好，複雜也罷，比如把支援的使用者數從100提高到1000，改變產品方向（Yelp原本只是一個向朋友推薦餐廳、醫生等資訊的工具。後來才演變成了一個評論網站），換一種程式語言（我曾經參與過從Java變到.NET又變回Java的專案）——所有這些變動比從頭再來的成本要小得多！
譯者注：Yelp是美國著名商戶點評網站，創立於2004年，囊括各地餐館、購物中心、酒店、旅遊等領域的商戶，使用者可以在Yelp網站中給商戶打分，提交評論，交流購物體驗等。
正因為我們在軟體上有極大的靈活性，我們也能夠在開發的全過程中接受需求的改變。開發早期階段被挖掘出來的需求，在它們被最終實現之前往往會變動好幾次。
在建築的世界裡，設計師把一套設計圖交給建築工人的時候，還能有相當的信心他們可以正確理解。儘管還是會有一些關於變動的需求和溝通，但變動的程度不可與軟體同日而語。反觀軟體世界，我們並沒有有效的方式（即使是UML）來做到給開發者交付了設計圖之後就可以甩手不管。取而代之的是，我們要在客戶和軟體開發者之間持續不斷地進行一系列的會談。
軟體比建築更傾向於接受大幅度的改動！
人員
在建築行業，工人通常被認為是可以交換和替換的。存在這樣的假設：在造一間房子的時候，如果你把木匠換掉，結果通常是一樣的。
這在軟體世界裡可不是這麼回事！因為工具（程式語言和庫）和問題領域存在的複雜性以及變數，開發者、業務分析師、測試人員、使用者體驗設計師等人是不能隨處流動的。
那些認為軟體與建築有關聯的人想當然地以為，人員是可以替換和交換的。但那與事實相去甚遠！軟體的所有實質內容都是各團隊裡的人構建出來的，如果你把一個團隊成員替換掉，這會在以下三個主要方面對團隊帶來影響：
- 他們會失去只有那位前團隊成員才瞭解的知識；
- 他們必須培訓新團隊成員：他們在做什麼，以及最新的進展；
- 他們必須花時間與新人建立起有效的工作關係。
結果是，替換或增加一個新人把整個團隊的進度拖慢了至少3~4個月。從個案來看，新的團隊成員在完全發揮效力之前常常花費比那更長的時間。儘管建築行業在人員變動時也會遭受進度拖延的痛苦，但其痛苦程度是遠遠不及軟體專案的。
Fred Brooks（《人月神話》的作者）有一句名言：“向進度落後的專案中增加人手，只會使進度更加落後。”40多年過去了，這句話仍然有效！
結論
那些經常用來描述軟體的建築隱喻是錯誤的。可悲的是，因為有了這層暗示，我們把很多重點放在了錯誤的地方：
- 力求把需求預先定義清楚，而不是接受：變化才是常態；
- 強調架構和架構師的重要性，而不是接受：軟體是可適應的，可由團隊裡的任何人來改變；
- 假設人員是可替換的，並且時間問題可以通過增加人手來解決，而不是接受：每個人都是獨特的；
- 追求可預測性，而不是接受：我們的領域還沒有被很好地認知。
軟體與建築絕無關係！
我們不是在建造，而是在探索！
我們在客戶的問題空間裡探索。我們正在提出新的想法，而它們剛好用程式碼來表達。讓我們丟棄老的建築隱喻吧，因為它們會使我們通向未來之路的地基崩裂坍塌。持這個觀點的人可不止我一個哦！