這篇文章寫於2008年06月24日，到今天正好是整整十年。最近不知道怎麼突然在美國的社交媒體上又火了起來，我們節選了其中的一部分，原文鏈接：https://projectfailures.wordpress.com 你可以在這裏看到。原文作者用“來自地獄的項目”來形容這個極其可怕的項目。

先來看看它到底有多糟糕：

1. 600多萬行C++代碼
2. 5萬多個類
3. 代碼中使用的C++風格早已過時，只支持一個編譯器版本，而且這個編譯器版本僅存在於一個不再維護的操作系統
4. 基於CORBA
5. 提供數據庫軟件的公司已經破產
6. 每層上都有幾層來處理圖形用戶界面，其中沒有一個是由作者實際維護的
7. 在32臺並行機器上構建需要48小時
8. 運行一個用戶界面需要40到50個同步進程
9. 沒有動態庫鏈接:可執行文件大小在幾百M左右
10. 啓動時間約爲15分鐘
11. 平均崩潰間隔時間:30秒到30分鐘

接下來我來看看這個全世界最爛的項目的發展經歷。

發展經歷

1996年，法國政府打算開發一款軟件，複雜度並不高，外包給一家大型法國科技公司。政府預付了數百萬歐元，預計兩三年完成開發。

很快，該公司聘用了幾個開發人員來開始這項工作，隨着現金開始流入，每隔3個月左右團隊規模就擴大一倍。

7年後，這個團隊還沒有開發出像樣的產品。由於逾期，團隊面臨每天數千歐元的罰款。管理層決定降低成本，炒掉了所有之前的開發人員，並且聘用很多沒什麼開發經驗的新手。

10年後，鑑於這個項目依然糟糕的狀況，中層管理人員決定僱用一些具有軟件工程經驗的人讓項目重回正軌。這期間平均人事變動頻率是3個月（法國法定入職後最短可離職時間）。

12年後，這個項目還在持續，公司通過向政府提交越來越多的變更請求來彌補每天的處罰。

據說，又過了幾年，主要項目老闆因欺詐而最終被關進監獄。

用戶體驗

除了耗費10多年時間，用戶體驗也是爛得一塌糊塗。隨便舉個例子：

一名開發人員被要求去檢查爲什麼右鍵單擊界面應用程序會無響應。經過幾天的仔細檢查，他發現右鍵單擊工作正常，“只是”需要大約45分鐘的時間來彈出菜單。因爲每當右鍵單擊主窗口時，菜單都會從非常大的內容動態生成。

在某些時候，用戶報告說“從CD-ROM加載數據”根本不起作用。這個問題花了好幾個星期才弄清楚，最後這個bug報告被標記爲’已經解決’，因爲數據確實正在被加載。唯一的一點是，它需要7天時間來將700M數據讀入。

到底做錯了什麼

那麼這個團隊到底做錯了什麼才鑄就了這樣一個“地獄級”的項目？

首先，這個項目採用C++進行開發。不是說C++不好，而是C++是世界上最複雜的計算機語言之一。面對這樣一個無盡複雜的迷宮，不少極客毫不畏懼地深入研究，最後不得不碰得滿頭包。很多人在接觸過C++以後很快就轉向其他語言。這個項目裏，對這麼多沒有任何軟件軟件工程經驗的菜鳥實在是一場“煉獄”。

其次，這個項目有600萬行代碼。用任何語言來維護如此多行的代碼是一項艱鉅的任務。想象一下，一個團隊必須維護600萬行代碼，這在軟件工程領域是多麼瘋狂的事情。說的形象點，如果你想以每秒一行速度快速讀取所有的行，你將在屏幕前不合眼地度過70天。

接下來就是粗狂的版本控制。項目進行了好幾年以後，團隊中才有人提出了使用版本控制工具的想法。第一次嘗試並不令人滿意，因此團隊切換到另一個系統，然後幾年後又轉入另一個系統，每次更改都會丟失所有歷史記錄。最終選擇的工具是一個帶有圖形用戶界面的“災難”。專門組建了一個由四個人組成的團隊負責在版本控制軟件上處理大多數維護問題，其中包括如下內容：

– 做第一次checkout需要與版本控制團隊預約，通常在一週後授權。

– 未經中層管理人員授權，不允許編輯文件。必須事先告訴經理要編輯哪些文件，然後發送官方許可請求，然後向版本控制團隊提交，並在幾天內實施。

– 代碼的每一次修改都會觸發分支，這意味着必須合併所有收到的修改。你可能會認爲兩個人在同一個文件上工作是很少見的，但事實證明，大部分工作發生在同一個文件中。

– Checkin需要經歷一個痛苦的過程，通過這個過程你的代碼被自動化的錯誤檢測軟件審查，最終由中間管理人員審查。毫無疑問，這並不能解決bug增長速度比開發人員移除bug的速度更快的問題。仔細查看註冊錯誤的數量就會發現，每一次缺陷修正帶來的錯誤是修正錯誤的兩倍。

– 版本控制確實很簡單。舊軟件是版本1，今天的軟件是版本2，未來的軟件是版本3。沒有人能真正知道哪個版本已經交付給客戶。

然後是人件(Peopleware)的因素。俗話說：付出與回報成正比。由於有很多人沒有任何軟件工程經驗，bug不斷涌現一定也不令人意外。一個真正聰明的經理必須意識到，在一個純軟件項目中，人力成本是成本的主要來源。公司並沒有遵循這一規則，而是決定解僱所有有開發經驗的人，但將所有的項目經理留在公司。

還有一點特別不正常的是團隊中有55人，20位開發人員，35位管理人員。沒錯，管理人員比實際開發人員還多。經理們不斷地組織會議，反覆地展示同樣的PPT，而開發人員則在寬敞的開放式辦公室裏閒聊以消磨時間。

很少有經理有軟件工程方面的經驗。當時SCO正就Linux問題起訴IBM。即使整件事只是虛張聲勢，但它確實對這些人起了作用，這些人都明白，他們很快就必須爲自由軟件付費。他們中沒有一個人提到過“自由軟件”，但他們都知道“免費軟件”。不用說，這個項目到處都用到了GNU庫，這些人完全不知道這會把整個項目變成一個巨大的、不兼容GNU的項目。但是，考慮到這個項目糟糕透頂的品質，沒有人會堅持要他們發佈軟件源代碼。

最後要說的就是糟糕的人力管理。隨便舉幾個例子你就懂了：

– 9點以後上班是不允許的。有一天，現場經理呆在大門後面，當場解僱了上午9點01分以後進來的所有人，包括一些經理和銷售人員。

– 吸菸者需要時不時出去來一根，因此做事情會比較慢。管理層試圖強迫所有人強制停止吸菸，但並沒有起到作用。

– 喝咖啡的人比不喝咖啡的人寫的慢，所以每個月咖啡機都會“壞掉”幾天。

– 每當官員來訪時都會關掉咖啡機，給人留下每個人都在工作的印象。

– 廁所是我見過的最噁心的。他們也許是這麼想的：在廁所花更少的時間，你工作的時間更多更好。

最後，如果你覺得你的工作太糟糕了，就想想這個項目……