春節前和同事在回家的路上看到了建築工地，不由的感慨建築業相比軟件業來講實在是成熟太多了！ 想想看，建築師設計好圖紙，交給建築公司（大包工頭）， 大包工頭再報給小包工頭， 小包工頭隨便抓一些農民工就可以幹活了！ 農民工們可不懂得那麼多高深的建築原理， 對整個建築也並不瞭解，可是他們只需要把自己的一磚一瓦做好，整個建築就能做成了 -- 當然也有豆腐渣工程-- 但畢竟是少數，排除在外。
更重要的是他們根本不用擔心項目的後期客戶突然想改設計方案，客戶不會也不可能要求你把朝北的窗戶挪到南邊去，也不會要求把10層樓中的第3層和第7層扒掉重蓋。
我們這些苦苦掙扎的碼農們肯定會想， 什麼時候軟件業也能這樣啊，什麼時候我們也能快樂編程，按時上下班，或者以後這些底層的Labor work都讓機器人做了， 我們都去做需求，架構，設計， 然後項目按進度，高質量的完成， 大家都很happy...
但是無數的無情現實告訴教育我們：別做夢了，這是絕對不可能的， 至少在可以預見的時間段(比如50年)是不可能的， 原因就在於軟件的複雜性，在現有的技術情況下， 軟件的固有複雜性無法解決， 只有依靠我們這麼碼農們去彌補。
爲什麼軟件這麼複雜， 爲什麼我們無法像建築業蓋房子，汽車業裝配汽車一樣去寫軟件？
1. 需求的複雜性
布魯克斯在著名的《人月神話》中提到軟件的內在複雜性， 的確，軟件系統的複雜性遠遠超過建築業和製造業， 軟件的需求是在人的腦子中的， 用自然語言都很難完整、準備的表達出來。 一般情況下，人們只有看到一個運行的系統以後纔會說： “奧， 我要的其實不是這個... ” 這是傳統的瀑布方法失敗的重要原因。 需求的不確定性是導致軟件複雜的重要原因。
2. 原始的工具
即使需求很複雜，如果我們有強大的， 靈活的工具， 比如以自然語言來寫程序， 我們也能處理。
但現實是殘酷的， 我們只有計算機語言， 它相當的原始， 從二進制語言，到彙編語言，再到高級語言，其最基本的、最核心的東西依然是順序，循環，分支， 即使加上面向對象，動態語言，庫， 框架，計算機語言的本質仍然沒有改變，就像牛頓三定律一出現，整個力學大廈已經建立起來了，後人只是在大廈和某些房間裏做裝飾而已， 使用計算機語言這種原始的工具，怎麼能夠表示複雜的需求？
3. 軟件組件之間的高耦合性
程序員的出現正是爲了填充複雜的需求和原始工具之間巨大鴻溝，程序員需要用自己的大腦，使用極其”原始“的工具， 把無法準確表述的，尚在腦子中的需求映射到可執行的代碼上，其難度可想而知！
當然我們程序員也不笨， 在長期的鬥爭中，我們學會了分而治之，把一個問題劃分爲一個一個的模塊， 讓這些模塊低耦合，高內聚， 我們還學會了分層，讓各個部分的聯繫達到最小， 可是所有的這些努力只是把複雜性降低了一點， 本質的複雜性依然存在。
普利司通製造的輪胎幾乎可以用到所有的汽車， 但是我們程序員無法開發一個登錄模塊，讓它用到所有的軟件系統中， 我們程序遠遠必須要對這些框架，庫進行定製，進行二次開發才能適應需求，這樣的工作必須通過手工完成。
在某些業務領域例如電力，金融，財務等也許能出現一些重用性很強的“輪胎”， 但很明顯不具備更大範圍的通用性。
所以在現有的條件下， 不管用什麼技術，組成軟件的各個組件之間依然是高耦合的(對應傳統產業而言)， 高耦合會帶來巨大的難以想象的複雜度。