泰安APP開發：軟件完*按照我們的指示行事。軟件失敗的原因在于我們告訴它做了錯誤的事情。 關于工程失敗我們標準的思維框架是在二戰后不久形成的（在軟件出現之前，針對機電系統）。其想法是通過把部件做得可靠（比如引擎可承受40000次起飛與降落周期）以及為那些部件故障做好預案（準備2個引擎）來把東西做得可靠。但軟件不會壞掉。Intrado的錯誤閾值不像導致飛機失事的缺損鉚釘。軟件完*是按照人的吩咐行事的。實際上軟件執行得非常完美。它失敗的原因在于它被告訴做了錯誤的事。軟件失敗是理解的失敗以及想象的失敗。Intrado其實是有個備份的路由器的，如果能自動切換過去的話，幾乎**能恢復911服務。但“當時發生的情況是應用邏輯并沒有要執行自動修正行動。” 這*是通過代碼而不是實體做東西的麻煩。如Leveson總結那樣：“復雜性是肉眼看不見的。” 現在正在進行的改變軟件制作方式的嘗試似乎都始于同*個前提：代碼實在是太難琢磨了。那么在試圖理解這些嘗試之前，弄清楚為什么會這樣是值得的：是什么讓代碼對大腦那么陌生，跟之前的東西那么不*樣呢？ 技術進步往往會改變世界的樣子——你可以看著道路鋪設下去，你可以看到天際線的崛起。但在今天你很難說出什么東西進行著了再造，因為這些東西經常是由代碼重構的。比方說，當你踩了汽車油門時，你不再直接控制任何東西；腳踏板與風門之間并沒有機械連接。相反，你只是給軟件提交了*條命令，給引擎補充多少空氣是由后者決定的。汽車*是你可以坐進去的計算機。方向盤和踏板*樣可以是鍵盤的按鍵。 跟*切其他東西*樣，汽車也被計算化以促進新功能。當*個程序負責風門和剎車時，在你距離另*輛車太近時它可以放慢車速，或者控制燃油噴射來幫助你省油。當它控制轉向器時，它可以在你開始漂移時保持在自己車道內，或者引導你進入停車區。沒有代碼你實現不了這些功能。你可以試試，沒有代碼的汽車*會變成龐大的、重達40000磅但無法移動的發條裝置。 軟件讓我們做出了有史以來*復雜的機器。但是我們幾乎都沒注意到，因為所有的復雜性都被包裹進小小的芯片里面以及數百萬行的代碼之中。但僅僅因為我們看不見復雜性并不意味著它*沒有了。 *的荷蘭計算機科學家Edsger Dijkstra在1988年曾經寫到：“必須思考*個頭腦此前從未面臨過的概念層級。” Dijkstra把這當成*種警示。隨著程序員熱切地想要把軟件植入到關鍵系統當中，軟件日益成為建造世界的關鍵——Dijkstra認為他們已經高估了自己。