福斯無法打爆特斯拉，原因出在聰明的工程師會寫出糟糕的程式

公司爆出類似問題，往往都會搞到高層下台。有時候很合理，像波音前總裁米倫伯格（Dennis Muilenberg）為737 Max事故下台，就是個例子。但實際上，軟體相關的事情確實很棘手，企業也非常難跟上軟體的發展。

先從電腦程式本身談起。寫程式需要結合許多不同的知識與創意，光是打錯一個標點符號這種小錯誤，就可能完全改變系統表現。從業界的經驗法則來看，工程師每寫1000行程式碼就會犯0.5到50個錯誤，由於汽車和飛機所用的軟體中，涵蓋了幾千萬行程式碼，因此實際上根本不可能做出零錯誤的系統。即使程式中的錯誤不會帶來大災難，也會持續拖累企業的生產力。行動支付金流服務商Stripe所做的調查指出，一般的程式開發人員每週要花21個小時修改老舊或錯誤的程式碼。

廣告

寫程式原本就有這些難處，但軟體工程這項專業本身的問題，放大了這些難點。在微軟當了20年開發人員的巴爾（Adam Barr）在《軟體困局：為什麼聰明的程式師會寫出糟糕的程式》（The Problem With Software: Why Smart Engineers Write Bad Code）一書中，剖析了這樣的現象。巴爾指出，許多工程師至少有部分靠自學，導致他們養成壞習慣，但程式課程又沒有辦法修正那些壞習慣。

產學之間太少溝通，針對學校要教什麼或應該為學生培養哪些習慣，也未能達成共識。巴爾認為，這樣的結果就是軟體業中的專業標準，經常被約定成俗或流行的做法取代。

巴爾在說明軟體業的基礎多不穩固的時候，舉的例子之一就是Google、蘋果等科技公司很愛用的面試手法：讓面試者在白板上解程式問題。其他領域很少出現這樣的場景，因為公司會預期只要自己找來的是從學校畢業的申請者，就應該具備基本的能力。就像醫生找工作不會被考解剖學，機械工程師也不需要寫下牛頓運動定律證明自己的實力。

廣告

軟體業瞬息萬變的特質使情況雪上加霜。就算是一套成功運作的系統也會快速過時。

英國銀行之前闖的禍一大部分就要歸因於它們試圖維持「祖傳」（legacy）系統，那些系統的設計者（通常是外包人員）早就離職了，他們使用的電腦語言，現在的人已經忘得差不多，系統建立時追求的標準，也根本沒人記得了。工程師如果為了新增亮眼新功能而面臨壓力，經常會選擇抄捷徑，導致問題累積到未來，而那個未來來得愈來愈快。

一名在產業打滾幾十年的專家分析，這樣的結果就是漂亮的新系統會快速退化成搖搖欲墜、外人一知半解的過時裝置，用封箱膠帶跟幾句禱告繼續撐下去。

直到有一天，成本高到無法忽視，企業不得不更新系統。但那個時間點就是危險性最高的時候，因為新的軟體必須做到那個大家一知半解的舊軟體可以做到的所有事情，甚至得做得更多。用一個老掉牙但再合適不過的形容來說，就像是要在行進間重建一架飛機。

廣告

福斯正竭盡所能地要消弭ID.3時髦功能的所有問題。公司希望可以將大部分的軟體開發工作移回內部處理，已經砸了70億歐元（約當2400億新台幣）成立閃亮的新「數位部門」。那八成是個好主意。然而，就像巴爾主張的，寫程式存在結構性問題，那也意味著砸錢在這個領域不盡然就會成功。Tesla或Monzo這種新創企業的優勢在於，內部工程師拿到的是一張白紙，沒有前人留下來的舊系統要維護，也比較少既有錯誤要修正，它們的軟體更強，開發人員可以花更多時間好好推出顧客想要的功能。

不過，新創的優勢終究只是暫時的，程式錯誤會悄悄潛入，搞砸的工作會一直在那裡。開發人員會離開，把知識一起帶走。

今天這些精力充沛的篡位者終有一天會成為笨拙的在位者，被自家古老、不可靠的科技拖累，並面臨下一次的顛覆。

（本文由「經濟學人」獨家授權轉載）
 

廣告