這三篇讀後感原來發布在我自己申請的域名 yishan.cc 上面，後來這個域名被牆了。
（原文寫於2008年12月）
幾個星期前，我給《現代軟體工程》課的每一個團隊都發了一本 《Dreaming In Code》的中文版 《夢斷程式碼》，要求寫讀後感。這本書講了這樣的故事：一群很有經驗的程式碼牛人在先進軟體開發模式的指導下，沒有資金壓力，在更多大牛的帶領下，原計劃用一到兩年的時間開發出一個備受期待的個人資訊管理軟體(PIM)，後來花了七年時間才完成這一創舉，但是已經無人喝彩。我是9月份讀的英文版，後來又翻閱了中文版，也有一些感想如下。
1）驅動
到底是什麼驅動程式設計師和管理人員，測試人員長年累月投入到一個軟體專案中去？
有理論認為，傳統的軟體公司用工資，職位，績效考核等讓一群經過面試和培訓的人在嚴格定義的流程下一起工作（大教堂/Cathedral模式）。其實，用開源，社群，共享的模式會更好（集市/Bazaar模式）也許更好。正如在第26頁所說的 [所有頁碼都是指英文版]
… it maps an alternate universe for programming in which time is simply less important because the work is cooperative rather than corporate, the workers are all volunteers, and the motivation is fun and ego, not financial reward. [p26]
這理論聽起來很好，但是我想起了兩個故事：
1) 美國的一個肥皂劇Seinfield裡有一集，講了一個混混Kramer 熱心地加入了一家公司，義務打工，起初他的口頭幽默和熱情感動了團隊，領導委以重任，不料Kramer 根本沒法兒把事情做好。最後領導只好找他談話，Kramer 承認自己不行，他說- 但是俺是義務給你們打工的！ 領導說，對，這就是讓我們為難的地方。。。 專案中來了一位“義務打工的”，照理說，對專案只有幫助，而且別人是“義務”，你怎麼好意思把別人趕走？
2) 我以前在西雅圖的時候參加過一個非營利組織，成員們都是有熱情為社群服務，而且義務付出。但是後來有些成員就逐漸找不到了，一些事情也不了了之。 由於大家都是義務貢獻，你沒法如何要求別人。
在Chandler 專案中，Andy Hertzfeld 就是這樣一個義務作貢獻的大牛。但是他也遇到了同樣的"志願者問題" –
They don’t know whether to count on you or not. And because you’re not getting paid, there’s lack of control. [p167]
後來這位Hertzfeld 也拍拍屁股走人了，大家可以為 fun 和 Ego 一起工作，但是如果fun 和 ego 都得不到滿足，或者，那motivation 也會急劇下降。
2）責任 和驅動緊密相關的，是責任 – Accountability.
在 Hard Drive 這本書中，講了這樣的故事 – 由於Windows 一再拖延，BillG 最後跟 SteveB 說 – 如果今年下雪之前Windows 還沒出來，你就別在這兒幹了。 書中沒有詳細講 SteveB 回頭來又和他的團隊講了什麼，但是第二天一個員工揹著睡袋進駐了辦公室。
很多年以後，Windows Vista 也經歷了很長的拖延，在又一次宣佈拖延之後，人們發現 Windows 團隊中一個赫赫有名的 VP 已經卷起鋪蓋走了。
我們回過頭來看，在Chandler 專案長達7年的拖延中，有沒有發生過各位專案管理者引咎辭職的事？ 好像沒有。 [有不少人離開，但是沒有人直接為專案延期負責] 既然我上一次拖延沒有什麼懲罰，那我為什麼一定要拼了老命要避免下一次拖延呢？
在傳統意義上的軟體公司，如果專案延期，那專案原計劃的收入就拿不到，拖延的時間再長一些，員工就得走人，否則整個公司都被拖垮了。在“集市”，社群，共享的模式下，大家都是義務，大家都在玩票，大家都做貢獻，但是對最終專案不直接負責任，那到底誰負直接責任呢？
在《移山之道》 中，我講了下面的例子：
阿超：我今天在“頂球”網咖看到大牛他爹在下棋，圍觀者支招的不少，有的說上馬，有的說拱卒，有的說出車。大牛他爹一會兒招法就亂了，眼看局勢不靈了，圍觀者一鬨而散，老崔後來也沒法，只好認輸了。
一個圍棋國手在一次重要的對局後，聽到旁觀者對棋局的程式有很多不同的看法，他也沒有過多爭辯，只是說：“無責任的旁觀者和有重大責任的當局者的看法自然是不一樣的”。
無責任的旁觀者在支招後，如果不靈，他可以面不改色地繼續支招，甚至可以給另一位對局者支招，不管最後誰輸誰贏，旁觀者隨時都能安心地離開，回家吃飯。有重大責任的當局者在走了損招或敗招之後，他很可能就要認輸下臺，丟掉比賽的獎金和頭銜。
我在清華大學的這一次《現代軟體工程》課，我發現有些學生好像不是特別投入，後來瞭解到，由於申請學校用的GPA只計算前三年的成績，第四學年課程的分數就和申請學校沒有什麼關係了，所以比較“雞肋”。有一個同學說，如果這門課是在第三學期，那許多同學們會非常計較分數，排名。現在，只要能過就可以了。這也許解釋了不少專案中出現了“花最少的努力能過就行”的心態。
一個軟體團隊可以制定出動人的遠景/Vision， 但是如果大家沒有搞清楚驅動專案的各種因素和每個角色應付的責任，那Vision只是一句話而已。
時間和交流：時間對每一個人都是公平的，對每一個軟體專案也是這樣。
nearly all software projects require only 1/6 of their time for the writing of code and fully 1/2 of their schedule for testing and fixing bugs. But it was rare project manager who actually planned to allocate developers’ time according to such a breakdown. [p17]
書中援引理論家的話說，最高效的軟體團隊規模應該是一個人，因為這樣就不用交流了。 隨著人數的增加，依賴關係的複雜，新手，老手員工之間的不同步，交流的成本會隨著幾何級數增加。在這裡插播一個有獎竟猜：
|
當Windows 研發團隊在開發Windows 2000的時候，團隊內部每天有多少封e-mail 交流？ a) 90 b) 900 c) 9,000 d) 90,000 |
對每一個團隊成員來說，他/她不僅要完成手頭工作，還有報告自己的進展（通過email 或其他形式），回答別人的問題，瞭解其他人的進展。每個人的時間都是有限的，那怎麼能保證我們在應付所有的交流/溝通之後，能有時間完成“手頭工作”？
一個微軟的同事前兩天跟我說，他們最近沒寫什麼程式碼，集中精力做“planning” 去了，大家寫了很多PowerPoint，改了很多PowerPoint。然後給VP, General Manger 做了兩輪彙報，然後根據VP們的意見再修改，再彙報。。。 PowerPoint 的風格變得非常專業和花哨，但是他們仍然沒有完成Planning，進入實質開發階段。華麗的 PowerPoint 中的每一個條目，也需要花PM 很多時間才能寫明白，讓VP 瞭解，同時也要花一線dev/test 很多時間才能實現，但是VP，PM 和 Dev/Test 面對同一個條目，他們心裡想的是同一回事麼？
外部交流
在Chandler 專案中，幸運的是，他們沒有這麼多VP 要彙報 （真正的VP – Al Gore 只露了一個小臉），但是我注意到他們用於交流的時間也非常多。例如
Every day the developers shared a chat room via Internet Relay Chat (IRC) [p139]
1 internal and 4 external email list set up.
blogs, wiki’s…
這些都是花時間的！我看到團隊成員還要回復素未謀面的愛好者的各種問題（例如質問他們為何不用某某框架，等等），當然這種透明度也滿足了很多人的好奇心，開源，社群的優點麼。。。 另一方面，專案管理人員發現他們面對著大量的任務沒有時間完成。就像第一章 Doomed 的開篇就說到：
John is doomed, he has 500 hours of work scheduled between now and the next release… [p11]
團隊中其他人也好不到哪裡去。那在這種情況下，是花時間繼續參加各種討論，blog，提供透明度 （Transparency），滿足大眾的好奇心，還是集中精力把自己“手頭的事” 搞定？我從書中沒有看到經驗豐富的管理人員這時候採取了什麼措施。事實上，在產品釋出之後，沒有證據表明，那些在IRC，Email，BBS 上發了很多議論的愛好者未必真正下載並使用你根據他們的意見開發出來的軟體。那這麼忙於交流是為嘛?!
事實上，這麼多交流和資訊並不能幫助人們回答一個最重要的問題 –
What had each programmer accomplished in the past week, and what task was next? [p141]
我的故事 – 在MS Outlook97 釋出之後，網上對這個V1 版本有很多意見，也有很多期待。 其中很多使用者在 NewsGroup (新聞組) BBS 上發表了強烈的建議，要求Outlook 支援直接閱讀 NewsGroup/BBS 的內容，當時只有Outlook Express 有這個功能。Outlook 的開發成員一度認為使用者的要求太強烈了，如果我們沒有這個功能，可能V2就會很不受歡迎 （幾個dev 已經做了一個初始版本）。 但是大家仔細分析後發現，在BBS上強烈發言的，就是那麼幾個人，因為他們老用BBS，因此他們的需求特別強烈，並且好像聲勢浩大，但是別的大部分使用者根本就不上BBS，因此也沒機會表達意見。所以Outlook 決定不做 NewsGroup 的功能，一直到現在。
內部的交流
除了外部的交流，還有內部的交流，隨著一個人經驗的增多，會有很多其他人來找你，為大大小小的事諮詢你的意見。然而你自己也有無數的任務要完成，怎麼辦？微軟的員工對這種情況也不陌生，微軟團隊允許一些人 “Go Dark”，他們可以關起門自己幹活，敲門不答應，不回答一般的email，不參加會議等等。
據說很早以前，BillG 把開發OS/2 API 的任務交給了一個牛人，這位前輩接受任務之後，並沒有開新聞釋出會，建立email distribution list, 或者QQ 群，而是掛了一個和下面類似的牌子在辦公室門外，把門一關，一個人悶頭開發去了。
不要打擾、投喂辦公室裡的動物
我們知道交流很重要，但是軟體不是在QQ 群中交流出來的（當然，有人在QQ 群中交流別人寫好的軟體），而是一些人一行行寫出來的。 這個過程需要集中注意力，避免打擾。在一個 “集市” 風格， “共享” 的開發氛圍中，如何能保證關起門來開發呢？
遠慮和近憂
Kapor 的團隊看起來非常重視“遠景”， 他們似乎沒有近憂 – 這也許是致命的。
他們對於軟體的基本架構/infrastructure 非常關心，例如對於儲存系統，它們提出了下列需求：[p103]
- it has to make life easy for the Python programmers
- it has to operate efficiently over a network
- it needs to be able to handle very large individual date items and very large numbers of items
- it has to be reliable, using database "transactions."
- it has to support searching and indexing
- [0] User experience //Kapor 後來加上去的，似乎不相干的一條遠景。
後來對於Data Storage，又有如下構想：[p109]
- Provide programmers with as revolutionary a data model as users
- data can live anywhere.
- Data is safe from corruption.
- Data is quick to get.
- Data can be large.
非常令人佩服的遠慮。 如果一個專案能同時實現其中3個目標，就已經能實用並吸引客戶，開始賺錢了。 但是Chandler 專案的同志們不滿足於只實現兩三個，他們要實現全部5個夢想。
一群牛人在 “沒有近憂，只有遠慮” 的條件下討論問題，最後只能議而不決。 在一次次延續到深夜的討論中，有人感慨 – "How is this night different from all other nights?" //[p110]
沒有近憂，或者說不用為近憂而負責 – “我們這個月的目標沒完成不要緊，但是我們的遠景一定要討論好”。 導致了專案不能收斂 – 一個專案的一個里程碑中，不確定的事情應該越來越少，bug 也越來越少，直到產品釋出。
Making firm technical choices was hard in the absence of a settled design, and settling on a design was hard in the absence of a technical roadmap. [p150 – 151]
正因為大家沒有近憂，所以大家可以繼續等待，設計要等技術決定後才好做，而技術的選擇要等設計決定後才好開始。就這樣，大家折騰到2005年的時候，他們才從高瞻遠睹的遠慮的雲端中下來，有了第一個腳踏實地的計劃：
But for the first time, at least, they could see they had a plan grounded in reality, rooted in estimates that … [p232]
Kapor 畢竟是聰明人，很多年以後，他說到了教訓：
We’ve consistently overinvested in infrastructure and design… [p342]
收斂的另一個特點是 – 做過了的決定，就要執行，不要反覆。事實上，Chandler 團隊在很多決定上搖擺不定。 架構師Hertzfeld 度假回來，發現他帶領其他同事奮戰一個夏天得到的 Document Architecture 被扔到一邊，原來 Kapor 決定 “We’ll have to come back and realign things” [p168]。 如果你是做義務勞動的 Hertzfeld，你還能做下去麼？
回到 “遠景”， 我相信幾乎沒有合適的解決方案能滿足“遠景” 中的所有要求，很難找到 “多快好省” 的解決方案（書中提到 fast|cheap|good 不能兼得，這也是MSF 中 time | resource | feature 三個元素的矛盾）。但是往往存在若干方案，從不同的角度逼近最優，但是有各自令人討厭的缺點。我們能否有智慧來選擇這樣一個方案，把近憂，遠慮都慢慢解決？
我自己在微軟正在做一個創新專案，前幾天一位加入這個專案不久的優秀的開發人員對我說，我們去年設計的資料庫問題太多了，如果我們早就像我這樣設計，估計會好很多。我不是資料庫的專家，我只能對他說，如果我們當時堅持要做到今天這樣才釋出，這個專案也許就做不到今天了。
換句話說，正是因為早期那些不完美，但是及時的設計，讓後來者有挑剔這些不完美的奢侈機會。
我們每個人在使用這些不完美的軟體（Windows, Outlook, 甚至Linux）的時候，都應該感謝當初設計者做出了正確決定，而那些堅持完美設計遠景的專案，它們都到哪去了？