兩個程式設計師的故事

“自動”僱傭了一位分析程式設計師，艾倫，來解決這個問題。

而“統一”決定試一下新來的初級程式設計師查爾斯，看看他是否有真本事。

艾倫做過一些複雜專案，有著豐富的經驗，決定採用PQR結構化方法來開發這個程式。於是他找到部門經理，要求增派3名程式設計師組成一個專案小組。這個小組於是開始工作，搗鼓出初步的專案分析報告。

“統一”這邊，查爾斯抽了點時間想了一下需要解決的問題。同事們常常看到查爾斯把腳翹在辦公桌上喝咖啡。偶爾見到他坐在電腦前，但是那有節奏的鍵盤聲告訴別人他其實在玩小蜜蜂。

不久，“自動”的小組開始編寫程式碼了。程式設計師們一半的時間用來編寫編譯程式碼，另一半的時間待在會議室裡，討論模組間的介面設計。

查爾斯的同事發現他終於不再玩小蜜蜂，而是一半的時間把腳翹到辦公桌上喝咖啡，另一半時間在紙片上塗寫著什麼。他好像不是在紙上玩“井字過三關”，但看起來不像是在寫有用的東西。

兩個月過去了。“自動”的小組終於釋出了專案時間表。計劃再過兩個月，他們就會發布程式的測試版本。然後再經過兩個月的測試和改進，就可以釋出完成版了。

此刻，對於查爾斯的遊手好閒，他的經理再也看不下去了，他決定批評查爾斯一下。但當經理走進查爾斯的辦公室時，他卻驚訝地發現查爾斯在電腦前正埋頭寫程式碼。於是他決定把批評先放一放，隨便跟查爾斯聊了一下就離開了。然而從此他更加註意觀察查爾斯的表現，想借機批評查爾斯。不過不愉快的對話並沒有發生，他很高興地發現查爾斯一直在寫程式碼。人們偶爾發現查爾斯推遲了午餐，且一週還主動加2、3次班。

第三個月的月底，查爾斯宣佈他已經完成了這個專案。他提交了500行的程式。程式清晰可讀，測試中符合所有的功能要求，甚至具備了一些更加便利的功能，極大地提高了程式的易用性。測試後，程式除了有一處疏忽外，表現得非常好。

“自動”的專案小組到此時已經將4個主要模組中的2個開發出來了。在這些模組被測試的同時，小組繼續開發其餘的模組。

又過了3周，艾倫宣佈提前一週完成了程式的初級版。他提交了一份清單，列舉了尚需解決的一些缺陷。測試中，客戶發現了一些清單上沒有的錯誤和缺陷。艾倫解釋說這是意料之中的，畢竟這只是一個初級的版本，有錯誤很正常。

又過了兩個月，專案小組完成了程式的正式版，包含了2500行程式碼。測試中發現，這個版本完成絕大部分的最初需求。程式功能上有一兩處遺漏，且對於資料輸入的格式要求非常嚴格。但公司最終決定使用這個程式，他們可以訓練打字員嚴格按照要求輸入資料。對於那些遺漏的功能，交由維護程式設計師去新增。

後記：

一開始經理對查爾斯的能力印象深刻。可當他閱讀原始碼的時候，發現原來問題比自己開始想象的要簡單得多。現在看來，這種難度哪怕對於初級程式設計師來說也明顯太低了。

的確，查爾斯平均每天產出了5行程式碼，這略高於平均水平。但是考慮到專案複雜度是如此的低，略高的生產率也不足為奇。而且經理對他頭兩個月的遊手好閒記憶猶新。

業績評估中，查爾斯薪水的漲幅大概是同期貨幣通貨膨脹率的一半，他也沒被提升。又過了一年，他感到沮喪而離開了“統一”。

“自動”這邊，艾倫因為按時完成這個專案而受到表揚。他的主管翻了幾頁原始碼，發現程式碼符合公司的結構化程式設計規範。但他很快便放棄了閱讀程式碼的想法，因為它看起來相當深奧。他現在意識到專案的複雜度遠比當初自己設想的高，於是他再一次誇讚艾倫的成就。

專案小組平均每人每天寫3行程式碼，剛好是平均水平。但考慮到問題的複雜度，有平均水平就非常不錯了。艾倫被大幅加薪，作為獎勵，他被提升為系統分析員。

英文原文：The Parable of the Two Programmers