編者按：很多軟體專案開發時間大大超出了規劃的時間，投入大量資金和人力，都沒有實在的結果。如果你討厭你的程式設計工作，請認真閱讀這篇 2008 年的文章吧。法國科技公司為政府做的專案，預期兩三年，做了十二年還在做；6 百萬行 C++ 程式碼，經理比工程師多，人員素質極低。
幾年前，我在一家法國大型科技公司工作，為他們的一個軟體專案做諮詢師。在那段時間，我見識到了軟體工程工作方面最匪夷所思的一切，完全超乎我的想象。專案人員工作極度不專業，而更嚴重的是，工作環境完全無視人的尊嚴。我一度覺得去那裡上班就像坐牢。我只要舉幾個例子，讀者自然就有分曉。
工作內容
為一個政府部門開發一款軟體。
政府先付了幾百萬歐元的訂金，軟體開發耗時初定 2 到 3 年。公司僱了幾個工程師，開始了專案。每隔三個月，團隊人數就翻一番，以便讓資金不斷流入。
7 年後，專案還不成樣子，連雛形都沒有。每天公司都要交幾千歐元的罰金。於是，管理層決定節流，把經驗豐富的員工都辭退了，僱了些經驗少，甚至完全沒經驗的新人。
10 年後，專案進度實在太滯後，中層管理人員決定僱傭有軟體工程經驗的人，把專案拉回正軌。公司的員工每三個月換一批，也就是法國離職交接期的時長。
12 年後，專案還沒結束。公司每天給政府發的修改申請越來越多，以“補貼”每天繳納的罰金。此時已經是 2008 年。
專案資料
- 600 萬行程式碼
- 基於 C ++
- 50,000+ 類
- 使用的 C ++ 已經過時，“鎖死”在編譯器版本中，編譯器的版本只能一個作業系統上用。
- 基於 CORBA
- 專案使用的資料庫軟體背後的公司已經破產
- 圖層使用者介面有好幾個，但實際上每一層都沒人維護。
- 32 臺計算機上構建，需要 48 小時
- 執行一個使用者介面需要 40 到 50 個並行程式
- 沒有動態庫連結：可執行檔案大小在數百兆位元組範圍內
- 啟動時間約為 15 分鐘
- 癱瘓頻率：每 30 秒到 30 分鐘一次
沒有那個軟體工程師會說 C++ 很簡單。就其複雜程度而言，這或許是最難掌握的程式語言，就連創造 C++ 的幾個工程師都坦白說，他們自己也沒有完全掌握。
這種無底洞、大迷宮似的語言，還是有不少人揚言說自己已經掌握了，只要有機會，他們就敢用給你看。他們一猛子扎進這口深井，最後大多遍體鱗傷。看著一滿篇天書，花不知多少小時，也找不到癱瘓原因。人都是很聰明的，人生短暫，投入一段時間沒有回報，就會“棄暗投明”，改用其他語言，改做其他專案。
軟體一大，不管是什麼語言寫的，維護起來都很難。6 百萬行程式碼，就一個小團隊維護，只要想想就能發瘋。6 百萬可不是小數字，就算一秒鐘讀一行，也要 70 天不眠不休才能看完。
我再舉兩個例項，讀者就知道這個專案有多讓人崩潰。
有一個開發者被分配了這樣一個任務：找出在介面上點選右鍵，介面凍結的原因。他花了幾天時間，仔仔細細檢查，耗掉大半耐心之後，他發現，在介面上右擊後，其實沒有錯誤，只是內容選單要 45 分鐘後才彈出。每次使用者在主窗體點選後，選單是動態生成的，但是背後是巨量的靜態內容，因此耗時長。有些使用者反饋說“載入 CD”的命令完全沒反應。這個問題花了幾個星期才弄明白，但是最後，錯誤報告卻被標記為“已解決”，因為資料確實有載入，只不過是花了整整 7 天，才載入完 700 兆的資料。嗯，不然怎麼說耐心是美德呢…
版本控制，猶如脫韁野馬
好幾年過去了，團隊裡終於來了個人才，提出要用版本控制工具。第一次嘗試，效果不如人意，於是團隊決定換一個系統。又過了紀念，每次更新的歷史資料全沒了。最後，他們選擇使用一個瑞士的系統，圖形使用者介面簡直不堪入目。有一個四人小組全職負責版本控制軟體方面的維護問題，跟他們合作，我們常常面臨以下的問題：
- 第一次測試需要與版本控制團隊先預約時間，通常在一週後才授權。
- 未經中層管理人員授權，不允許編輯檔案。必須事先告訴經理要編輯哪些檔案，然後申請上級許可，再預約版本控制團隊，在幾天後才能編輯。
- 每次修改程式碼都會產生分支檔案，也就意味著必須合併所有修改。有了這麼多的檔案，你可能覺得，不會出現兩個人弄同一個檔案上的重複勞動。但事實證明，大家都在弄同樣的 100 個檔案。
- 檢入過程非常痛苦，這個過程中，你的程式碼經過自動化錯誤檢測軟體審查，最終由中間管理人員審查。不用說，bug 的出現速度永遠比開發人員糾正速度快得多。如果你仔細看註冊的錯誤數量，每次修正導致的新 bug 數量，是原來 bug 數量的兩倍。
- 版本控制很簡單。舊軟體是版本1，目前的軟體是版本2，未來的軟體是版本 3. 沒有人知道哪個版本已經交付給客戶了。
從前的某一天，公司安排過正式交付。但是這個時間不是團隊內的人定的。那天，客戶受到了一張沒有內容，只有安裝指引的光碟。那時因為，沒有人知道怎麼把這個專案做出來。後來客戶發現他們受到的光碟裡，什麼也沒有，於是給公司發了封正式的投訴信。
公司居然把舊版本的軟體發給了客戶。客戶之所以能發現，是因為他們看了“說明”欄，裡面的內容跟上一年的版本大同小異。
“人件”
微薄薪水，只能僱庸碌之輩
團隊裡大部分人都是沒有軟體工程經驗的人，軟體裡要不是大部分都是 bug，就奇了怪了。經理意識到，一個單純的軟體專案，支出的大頭是薪水，真是天資聰穎。但是，這個大發現絲毫沒有影響 TA 炒掉工程師，不論他們有沒有經驗，卻把桌面上有“C++傻瓜入門”之類書的管理人員統統留下了。
我們的夢想團隊
團隊 55 人：20 個開發者，35 個管理人員
沒錯，管理人員數量比工程師還多。
管理人員最擅長的就是開會，講的都是同一個 PPT，一遍又一遍，講到吐為止。而開發者就在寬敞的共用辦公空間裡聊天解悶。
很多管理人員在軟體工程上毫無經驗。當時 SCO-Linux 爭議炒得沸沸揚揚，不管整件事算不算鬧劇，很多人都意識到，以後要用自由軟體都要付費了。）不用說，整個軟體到處都是 GNU C 庫裡的程式碼，一個巨型 GNU 相容的非共享軟體。但是，就這個專案的水準，估計也沒人敢把程式碼放出去。
自由軟體（free software），根據自由軟體基金會對其的定義，是一類可以不受限制地自由使用、複製、研究、修改和分發的，尊重使用者自由的軟體。這方面的不受限制正是自由軟體最重要的本質，與自由軟體相對的是專有軟體（proprietary software），或被稱為私有軟體、封閉軟體（其定義與是否收取費用無關──自由軟體不一定是免費軟體。
整個團隊，技術水平不如人意，瞭解網際網路的人屈指可數，其中自認為了解網際網路的，以為網際網路只是為愛情動作片而生的。他們之間，如果有人說自己在網上看了點東西，聽者就會露出會心一笑。
地獄之旅
本來在這裡的工作，雖然不算優越，至少不會無聊。但是頂層的管理人員非要採用納粹管理集中營的辦法來管理員工。我隨便舉幾個例子：
- 早九點後到崗是不允許的。有一天， 經理站在大門後，把 9 點整以後到的所有員工都當場炒魷魚，包括一些經理和銷售人員。
- 抽菸的員工，因為跑出去抽菸，工作的時間就打了折扣。所以管理層決定讓所有員工都不許吸菸。當然，沒有用。
- 有時候，一連好幾天咖啡機都被收起來。因為跑去喝咖啡的人自然沒有坐在辦公桌前的人、伏案寫程式碼的人工作時間長。
- 每次有上級來視察，咖啡機就要關掉，以便給上級留下大家都在桌前認真寫程式碼的印象。
- 那裡的洗手間是我去過的洗手間裡最噁心的。大概也是為了提高大家的效率：上廁所的時間少了，工作的時間自然就多了（工作質量自然也上去了）。
這樣的工作，這樣的管理，為什麼大家還要來上班？最主要的原因就是當時法國深陷經濟危機（某種程度上，現在也是），有工作，有薪水幾乎成了特權，工作環境、內容自然就沒那麼在意了。
還有一個原因，對於在那裡的大多數員工而言，這份合約算是他們與一家真實公司簽下的一份實實在在的合約。沒有對比，就沒有傷害，他們可能都不知道這份工作的糟心程度。很多員工新入職場，覺得遲到就被炒魷魚，也沒什麼不合理的。但是，這樣嚴苛的標準，晚一分鐘都不行，只有變態的管理者才會付諸現實。
話又說回來，政府怎麼會讓這樣的事情發生呢？但我們都心知肚明，政府裡管這個專案預算的官員和軟體公司的頂層管理人員拜過把子，關係夠鐵。在法國，這種程度的腐敗也沒什麼新鮮的。很多人根本不知道，更別說有什麼懲罰或者後果了。當然，也不限於法國，放眼歐美，這樣的故事也不少。
所以，下次上班覺得難熬，要學會置身處地。想像一下自己在那裡工作，會是什麼光景。