為什麼我們應該像蓋房子那樣寫軟體？
萊斯利.蘭伯特是一個電腦科學家，擅長分散式系統、時態邏輯和並行演算法。他是工程和國家科學院國家科學院成員。蘭伯特在麻省理工學院攻讀數學本科，在布蘭迪斯大學贏得了他的碩士和博士學位。他為微軟研究所工作。
在砌上一塊磚或釘下一支釘子之前，建築設計師會制定好詳細的計劃。程式設計師或者軟體工程師卻不會。這難道就是房子很少塌倒而程式經常會崩潰的原因？
藍圖保證建築設計師的設計的建築按規劃建成。“建成”不僅僅意味不會塌倒，還意味達到業主要求的功能。建築設計師和他們的客戶在著手建造之前，透過藍圖來溝通，以理解他們將要建造成的建築的樣子。
但是很少有程式設計師在編碼之前，會勾畫哪怕是簡單的草圖來說明他們的程式將是會怎麼樣子。
大多數程式設計師認為做任何不產生程式碼的事情都是浪費時間。思考並不會產生程式碼，沒有想好就開始編碼，那只是產生糟糕程式碼的菜譜。我們應該理解這些程式碼到底要實現哪些功能。理解需要思考，思考很難。借用一句漫畫家迪克.圭尼登的話：
寫作是一種讓你知道你想法有多傷感的本能方法
藍圖讓我們想清楚我們打算要建造的建築。在寫下一段程式碼之前，我們應該先寫藍圖。軟體的藍圖稱為技術說明書。
已經有太多的藉口說撰寫技術說明書只是浪費時間。比如：技術說明書毫無用處，我們不能透過它來產生程式碼。這就好像說建築設計師應該不要畫藍圖，因為他們最終還是需要承包商去建造房子。另外一個反對撰寫技術說明書的爭論也能夠用藍圖的例子來反駁。
還有一些程式設計師爭辯說，把藍圖和技術說明書作比較，是無用功，畢竟程式不是建築物。他們認為推倒一堵牆要比改變程式碼難多了，所以程式的藍圖不是必須的。
錯了，改變程式碼也很難，特別是如果我們不想匯入缺陷的話。
我最近為要加入一個小小的功能而修改一些不是我寫的程式碼。要完成它需要理解一個介面。我花一整天使用偵錯程式來找出該介面到底是幹什麼的–有時候需要花5分鐘讀讀技術說明書就搞定的事情。為了避免匯入缺陷，我不得不弄清楚我每次修改之後的結果。因為沒有技術說明書，這個事情變得更加困難。我必須要閱讀上千行程式碼，我花了數天來琢磨怎樣才能修改儘可能少的程式碼。最後，我花了一週，新增或修改180行程式碼。這可僅僅是這個程式的一個很小的變更啊。
修改程式碼只是一項大任務中小小的一塊工作，大多數程式碼已經是我十幾年之前寫的了。儘管我幾乎不記得這些程式碼是幹嘛的，要修改它還是挺容易的。透過閱讀我寫的技術說明書，很容易就找到我要修改的地方。儘管這些修改工作量不少，而且還影響到其它程式碼，我還是很快搞定它。
我所說的技術說明書到底是什麼東東？它經常被認為需要使用非常正式的技術語言。但是正式的技術說明書只是這光譜的一端，如果我們僅僅是蓋個工具棚的話，我們不需要畫摩天大樓所要求的那種藍圖。對於大多數軟體來說，我們不需要正式的技術說明書。然而，哪怕是小小的程式，沒有技術說明書都很傻。就好像要蓋一個工具棚，最初沒有畫一個哪怕是簡單的計劃那樣。
這些日子，我寫的程式往往只是像小房子而不是摩天大樓這樣的級別。我常常寫下每個演算法的實現方法，大多數演算法很簡單，可能需要一兩句話就能夠寫清楚。有時寫清楚一個演算法到底是怎麼起作用的需要好好構思，並可能花上一段話，或者幾頁紙來寫清楚。我有一個簡單的規則：技術說明書應該寫清楚該演算法的使用者需要知道的每一件事情。在程式碼寫好，編譯好之後，估計沒有人會再去閱讀它了。
我往往能夠指出一段程式碼是怎麼工作的，一些程式碼很直白，但另外一些並不是這樣，它要求很複雜的演算法。讓一個演算法運作起來，需要精心構思，這就要求技術說明書。
我寫的大多數技術說明書都是非正式的。偶爾一段程式碼很精妙，也很關鍵，這就需要正式地寫。要保證準確性，甚至要使用編寫工具仔細檢查。這種正式的事情過去十幾年只是有那麼十幾次罷了。
對於複雜系統的設計師，一份正式的技術說明書是必須的，就好像摩天大樓的藍圖一樣。但很少工程師會作撰寫技術說明書，因為他們根本沒有時間去學會做好這個事情，而且學校裡也不教。一些學校會講授技術說明書用語，但是很少教怎麼在實際工作中應用。如果你連一個工具棚的藍圖都不會畫的話，怎麼能會畫摩天大樓的藍圖？
要學會撰寫技術說明書，需要實踐。沒有簡單的規則來保證你寫出一份好的技術說明書。一個應該避免的事情就是不要用程式碼。透過程式碼去理解程式碼是一個糟糕事情。建築設計師不會用磚來製作藍圖。
理解一件複雜的事情的關鍵是抽象，這意味著比程式碼上一個層次。簡單和準確的最好語言是數學，初等數學就教過這些了：集合，函式和簡單的邏輯。不過，大多數正式的技術說明書使用的語言不在初等數學班裡，比如：型別。然而，越是遠離簡單數學的語言，越會妨礙我們去理解一個複雜的程式或系統。
無論是為複雜系統使用正式的技術說明書或者簡單程式碼的非正式的技術說明書。撰寫技術說明書會提升我們的程式碼質量。它有助於我們理解我們正在做的事情，並減少出錯。當然，即使撰寫技術說明書也不保證你的程式就不會崩潰。我們依然要使用已有的其它方法和工具來減少程式碼缺陷。
思考不會保證我們不會犯錯誤。但是不思考那肯定會犯錯誤。