代碼之道
原 書 名：I. M. Wright's Hard Code
原出版社：Microsoft Press
作 者：(美)Eric Brechner
譯 者： 陸其明
叢 書 名：Microsoft核心技術叢書
出 版 社：機械工業出版社
書 號： 9787111251675
頁 碼：192
定 價：36.00
編輯推薦
《代碼大全》姊妹篇！
微軟公司內部所有工程師的必讀之書！
——Peter Isensee，微軟公司開發經驗
“我能肯定，I.M.Wright不會聽我的話，試都不用試。”
——Jon DeVaan，微軟公司高級副總裁
“儘管我絕不會從這傢伙手裡買二手車，但在軟體開發方面，他確實也對他自己的東西知道得一清二楚。”
——Ian Ellison-Taylor，微軟公司工程部總經理
“微軟公司內部所有工程師的必讀之書。”
——Peter Isensee，微軟公司開發經理
揭示關於編碼、測試和項目管理的殘酷現實——一位微軟的內部人士如實地向你述說。I.M.Wright的“Hard Code”故意煽情，幾年來在微軟內部成千上萬的工程師之間引起了激烈的爭論。現在（也顧不上“家醜不外揚”了），我們把他的觀點向所有人公開。
本書收錄了49個欄目。Eric Brechner重拳出擊，對最令他苦惱的問題提出了最佳實踐的解決方案，另外還加上了他坦誠的註解。他解剖了開發過程，審查了棘手的團隊問題，批判了軟體業務的運轉方式——自始至終充斥著機靈的幽默和譏諷的風趣。他的想法並不總是很受歡迎（他也不關心那個），但它們的的確確激發起了人們的討論和想像，推動著軟體相關的活動走向卓越。
了解未經掩飾的真相：
怎樣提高軟體的質量和價值——從設計到安全；怎樣切合實際地管理項目的時間表、風險和規範書，怎樣為常見的低效率開發瘦身，怎樣套用過程改進方法——避免固執盲從，怎樣驅動一個成功的、令你自己滿意的職業生涯，怎樣不變成暴君——發展並管理一個欣欣向榮的團隊！
作者簡介
Eric Brechner，微軟公司“卓越開發”部門的總監，在軟體行業已經積累了20多年的經驗。他從2001年開始寫“Hard Code”欄目，作為一種資源提供給微軟的員工。自那以後，其觀點欄目在微軟內部成千上萬的軟體開發者之間，激起了無休無止的關於最佳實踐的討論——如今，這些觀點走出了微軟，走向了整個開發社區。
簡介
獻給當初對我說“為什麼不由你來寫？”的人：Bill Bowlus
你手上拿著的是一本關於最佳實務的書。它會比較乏味。但也許會比較有意義，你能從中得到知識，讀後甚至對你產生些許影響，但讀起來肯定還是乾巴巴而無趣的。為什麼這么說呢？
最佳實務的書是乏味的，因為這個“最佳”是跟具體的項目、具體的人、他們的目標以及偏好緊密相關的。一個實務是不是“最佳”，大家可能看法不一。作者必須把實務列舉出來讓讀者自己來選，並分析在什麼時候、因為什麼原因作出最佳選擇。雖然這種做法是現實的、負責任的，但也是令人厭煩的，最終無法取悅讀者。為釋疑而設計的案例研究會使文字有味一些，但作者仍必須把選擇的機會留給讀者，否則作者就會顯得傲慢、教條並且死板。
然而人們喜歡看到傲慢、教條、死板的學者之間的針鋒相對。大家喜歡引用學者們的觀點片段，與朋友和同事一起討論。為什麼不把這些最佳實務當作觀點欄來爭論呢？惟一的條件，就是要有人願意將自己扮演成一個思想保守的傻瓜。
本書的由來
2001年4月，在我歷經了Bank Leumi、Jet propulsion Laboratory、GRAFTEK、Silicon Graphics、Boeing等公司總共16年的職業程式設計師生涯，再在微軟做了6年的程式設計師和經理之後，我轉入了微軟內部的一個以在公司範圍內傳播最佳實務為職責的團隊。當時這個組正在運作發行名叫《Interface》月刊網路雜誌的一個項目。它很有意義，且富有知識性，但同樣也是乾巴巴而無趣的。我那時建議增加一個觀點欄目。
我的上司Bill Bowlus建議由我來寫。我拒絕了。作為一個半大孩子，我努力成為一個協調員，撮合多方產生成果。成為一個愛嘮叨的實務學者會毀掉我的名譽和效力。因此，我當時的想法是說服一個大家公認的小心眼的工程師來寫，他可能是我在微軟以前6年工作經歷中接觸過的一位固執的開發經理。
但Bill指出，我有22年的開發經驗，4年的開發管理經驗，寫作技巧也還行，而且有足夠的態度來做這件事。我只需要放下自身的心理包袱。另外，其他的開發經理都忙於常規的工作，不可能每個月來為我們寫觀點。最後Bill和我想出了一個用假名撰稿的點子，於是I. M. Wright的“Hard Code”欄目誕生了。
從2001年6月開始，我使用“I. M. Wright，微軟逍遙的開發經理”這個署名為微軟的開發者和他們的經理寫了49個“Hard Code”觀點欄。這些欄目的標籤行都打上了“絕對誠實，重拳出擊”的標語。每個月，成千上萬的微軟工程師和經理都在讀這些欄目。
前16個欄目在《Interface》內部網路雜誌上發表了。隨後同事（Mark Ashley和Liza White）給我分配了更多的主題。我和《Interface》的美工Todd Timmcke還一起製作了作者的很多搞怪照片。當網路雜誌停刊的時候，我才得以喘息的機會，但也停止了寫作。
14個月之後，在我們組的同事Amy Hamilton (Blair)、Dia Reeves、Linda Caputo、Shannon Evans和Marc Wilson的幫助下，我又開始在內部站點上發表我的欄目。去年11月份，我將所有的欄目轉移到了一個內部的SharePoint部落格上。
2007年春天，正當我打算休掉幾年前獎勵給我的假期的時候，我現在的經理Cedric Coco給了我在休假期間將“Hard Code”出版成書的授權。而微軟出版社的Ben Ryan也同意了。
除了我已經提及的人，我還想感謝《Interface》的其他成員（Susan Fario、Bruce Fenske、Ann Hoegemeier、John Spilker和John Swenson），其他幫助過本書出版的人（Suzanne Sowinska、Alex Blanton、Scott Berkun、Devon Musgrave和Valerie Wolley），支持我的管理層（Cedric Coco、Scott Charney和John Devaan），我現在的和以前的、複審過我的欄目並提出過很多主題的團隊成員（William Adams、Alan Auerbach、Adam Barr、Eric Bush、Scott CHENEY、Jennifer Hamilton、Corey Ladas、David Norris、Bernie Thompson、James Waletzky、Don Willits和Mitch Wyle），我才華出眾的中學英語老師（Alan Shapiro），以及那些慷慨給予我反饋的讀者們。特別地，我還要感謝我的妻子Karen和我的兒子Alex和Peter，他們讓我做任何事情都充滿信心。
本書的讀者
組成本書的49個觀點欄最初是寫給微軟的開發者和他們的經理看的，儘管它們也是我過去在軟體行業6個不同的公司、28年的工作經驗中提煉出來的。編輯和我一起修正了表達語言，註解了那些微軟內部的特殊用語，使得本書適合於所有軟體工程師和工程經理閱讀。
我在這些欄目中表達的觀點是我個人的，不代表我現在和以前任職過的任何一家公司，包括微軟。我在欄目中的註解以及本簡介中的言論同樣都是我個人的，與公司無關。
本書的組織方式
根據主題的不同，我把所有欄目分成了10個章節。前6章剖析了軟體開發流程，接下來3章重點討論人的問題，最後1章批判軟體業務運轉方式。用於解決這些問題的工具、技巧和建議遍布全書。本書的最後還附有術語表和索引方便大家參考。
每一章的各個欄目均按照當初在微軟內部發表的時間順序排列。每章開頭我都給出了一個簡短的介紹，隨後就是當初我以I. M. Wright名義發表的欄目內容。編輯成書的時候，我還適時在欄目中加上了“作者注”，以解釋微軟的術語，提供更新內容或者額外的背景知識。
編輯和我盡力保持了原有欄目的完整性。我們做的，僅僅是糾正語法和內部引用。稱得上改動的其實只有一處：就是將原來一個叫“你被解僱了”的欄目標題改成了“最艱難的工作”，因為以前那個標題太容易讓人誤解了。
每個欄目都以一段激昂的演說開場，然後就是問題根源的分析，最後以我對這個問題如何改善的建議結束。我酷愛文字遊戲、頭韻和通俗文化，因此欄目中充斥著對這些東西的引用。特別是大部分欄目的標題和副標題都直接取材於歌詞、電影對白和有名的諺語。是的，我自娛自樂，但撰寫這些欄目確實給我帶來了些許樂趣以及痛快的宣洩。希望你也會喜歡！
系統要求
本書提供的工具都是微軟的Office Excel 2003和Office Word 2003格式的。只要你的電腦上安裝有Word和Excel的瀏覽器，你就能使用這些檔案。
微軟的組織結構
因為這些欄目最初是寫給微軟的內部員工看的，因此簡要了解一下微軟以及我在工作中扮演的角色會有助於更好地理解這些文字。
目前，微軟的產品開發分成三大業務部門，總共有大概25條產品線，超過450個產品單元，和眾多的功能團隊。這些部門是平台產品與服務部門、微軟商業部門、娛樂與設備部門。部門內的產品線是由相關的產品套件整合在一起形成的，比如Office System和Visual Studio。
每條產品線包含了大約20個獨立的產品單元。通常情況下，這些產品單元共享原始碼控制、建造、安裝、工作條款跟蹤和項目協調，包括價值主張、里程碑安排、發布管理和工程支持。除了這些協調服務之外，產品單元還有高度的自主權，可以對產品、流程和人員作出自己的安排。
一個典型的產品單元通常有一個產品單元經理（PUM，Product Unit Manager）和三個工程工種經理：部門項目經理（gpm，Group Program Manager）、開發經理（Development Manager）和測試經理（Test Manager）。其他工程工種，比如用戶體驗、內容發布（比如線上幫助）、實施，可能單獨對某個產品單元負責，也可能在產品線或者整個部門中共享。
每個工種都要抽出一個或多個代表，以組成一個叫功能團隊的虛擬組織，來開發具體的產品功能。這些人的工作仍然匯報給各自的工種經理。有些功能團隊選擇敏捷方法，有些喜歡精益模型，有些採用傳統的軟體工程模型，有些則根據實際情況混合了上述多種方法。
微軟怎么能包容所有這些多樣性和產品的區域自治、還能為朝著一個共同的目標有效地工作呢？這就要靠產品線公共的項目協調了。舉例來說，產品線的價值主張為所有的產品單元和他們的功能團隊設定並統一關鍵套用範例、質量尺度和框架體系。
為了促進跨部門和產品線的協調和共享，特別是為提高質量和效率，微軟還設立了一個組織叫Microsoft Trustworthy Computing and Excellence。它是我的上級組織。具體來說，我的工作職責是，要讓微軟全球超過1萬名的開發者在構建令人興奮的、高質量的用戶體驗時，能夠做得更加開心、更富有效力。不用說，這是一項長期的工作。
我的團隊每月將開發部門的領導層聚集在一起，談論問題並指導我們的工作。我們研究公司範圍內乃至整個行業內的工程方法，以期找到新的機會和領域去提高。我們通過網路共享工具、最佳實務，以及實施職業生涯指導。我們舉辦各種活動和獎項評比，與各種團隊商討，為開發中的各個級別、各種角色提供技術培訓。非常棒的工作！另外，我每月還在寫著觀點欄。
示範工具和文檔
線上資料列表
工具 欄目 章節
Sprint backlog: SprintBacklogExample.xls;
SprintBacklogTemplate.xlt 敏捷子彈 2
Product backlog: ProductBacklogExample.xls;
ProductBacklogTemplate.xlt 敏捷子彈 2
Spec template: Spec template.doc 糟糕的規範書：該指責誰？ 3
Spec checklist: Spec checklist.doc 糟糕的規範書：該指責誰？ 3
Pugh Concept Selection:PughConceptSelectionExample.xls;
PughConceptSelectionTemplate.xlt 複審一下這個 5
Inspection Worksheet: InspectionWorksheetExample.xls; InspectionWorksheetTemplate.xlt 複審一下這個 5
Interview Role Playing, a how-to guide:
InterviewRolePlaying.doc 面試流程之外 9
本書的支持
為了保證本書及其附屬內容的準確無誤，我們盡了最大的努力。本書所有的修正和改動都會蒐集起來並放到微軟的知識庫中去。
問題和意見
如果你對本書及其附屬內容有任何意見、建議或問題，並且通過訪問上述站點仍然無法解決，請給微軟出版社傳送電子郵件，或者按照如下方式郵寄：
Microsoft Press
ATTN: I. M. Wright’s “Hard Code” Editor
One Microsoft Way
Redmond, WA 98052-6399
請注意，上面的地址對微軟的軟體產品不提供支持。
序
長期以來，我一直在閱讀Eric Brechner以I. M. Wright為筆名撰寫的欄目。當我第一次見到作者本人的時候，我費了好大的勁才讓自己相信，我是在跟同一個人說話。Wright先生非常地自以為是，然而站在我面前說話的人卻那么謙虛、彬彬有禮、非常友好，他看起來更像Clark Kent。（譯者註：Clark Kent是“超人”的名字，他具有超強的本領，是一個虛構的超級英雄，美國漫畫中的經典人物。）
我很關注微軟內部團隊在軟體開發的過程中，他們是如何去處理技術與人際交流之間的關係的；這類欄目總是我的最愛。看到大量的公司內幕被寫了出來，我常常會感到吃驚——我不知道還有多少不為人知的故事沒有說出來。
大型項目中的軟體工程管理者面臨著3個基本的問題。第一個是，程式代碼太容易被改變了。跟機械或土木工程不一樣，它們在現有系統上做一次改變總是要付出實實在在地拆毀某些東西的代價，而軟體程式的改變只需要敲敲鍵盤就行了。如果對一座橋的橋墩或一架飛機的引擎做一個錯誤的結構性更改，由此產生的後果，即使不是專家也很容易就能看出來。然而，如果在一個現有程式上做修改，對於其風險，即使經驗豐富的軟體開發者進行了充分的討論，其結果常常還是錯的。
建築隱喻實際上可以很好地適用於軟體。基於程式代碼在系統中所處的層次，它們可以被比作為“基礎、框架和裝飾”。“基礎”代碼具有高度的槓桿作用，它們的改動常常會引起嚴重的連鎖反應。“裝飾”代碼比較容易改動，而且也需要被經常改動。問題是，累積了幾年的改變之後，複雜的程式就跟歷經過幾次裝修的房子差不多了——電源插座躲到了櫥櫃的後面，浴室風扇的出風口通向了廚房。再做任何改變的話，其副作用或最終的代價都是很難預知的。
第二個基本問題是，軟體行業還太年輕，關於可復用組件的正確標準實際上還沒有被發現或建立起來。大頭釘是否應該放在離開16英寸的地方，以同時適應水平或垂直的4x8英尺的乾壘牆或夾板？我們不僅在這類問題上還沒有取得一致意見，甚至我們還沒有決定，是否像大頭釘、乾壘牆和夾板這樣的組合更可取，還是我們要去發明像泥漿、稻草、石頭、鋼鐵和碳化纖維這樣的組合。
最後一個問題實際上是第二個問題的另一種表現形式。每個項目中重複發明的軟體組件，它們也被重複命名了。軟體行業里對現有的概念發明新的名字是很常見的，即使用的名字相同，這些名字也以新的方式被重用。行業里有一個心照不宣的秘密：關於軟體開發最佳方法的相當多的討論，參與的實際上都是同一群人，只不過他們用了不同的名字，他們甚至對彼此正在說的東西都沒有一個哪怕是很朦朧的想法。
表面上看來，這些都是很簡單的問題。建立一些標準，然後強制實行它們。在快速進步的大容量、高價值、低成本的軟體世界裡，這可是一個讓你的業務落敗的捷徑。實際情況是，軟體最大的工程障礙，同時也是它最大的優勢。無處不在的軟體（運行在低成本的個人電腦和網際網路上），已經使得以驚人的步伐去創新成為可能。
隨著微軟的成長，公司已經不再能在最佳工程實踐的研究方面大量地投入，然後經過深思熟慮，挑選出其中具有最好質量的方法。個人電腦和Windows的成功，已經把公司從按傳統方式做些小項目的形態轉變出來，轉而要去譜寫開發有史以來最龐大、最複雜軟體的新篇章。
為了能夠創建出平衡風險與效率、創新的最佳系統，微軟面臨著持續不斷的掙扎。考慮到我們的一些項目有著極度的複雜性，這些努力甚至可以稱得上“英勇無畏”。在過去的一段時間以來，我們已經設定了專員、建立了專門的組織，他們都一心一意、致力於這個行業里最困難的事情——“軟體發布”。我們已經學會了很多的民間傳說、風俗、文化、工具、過程和大拇指規則（譯者註：Rules of Thumb，是指沒有經過科學實驗、直接從實踐中總結出來的方法和規則；它們在很多情況下都有用，但並不是放之四海皆準），那些都有助於我們建造和發布這個世界上最複雜的軟體。但與此同時，每天都處理這些問題難免也讓人心驚膽戰、士氣受挫。Eric的欄目正是大家跟我們一起分享和學習的極好方式。
Mike Zintel，微軟公司Windows Live核心開發部門總監
2007年8月
目錄
序
簡介
第1章 項目的不當管理
2001年6月1日：“開發時間表、飛豬和其他幻想”
芮氏規模估計
風險管理
客戶贏了
2001年10月1日：“竭盡所能：再論開發時間表”
軟體工程絕對是含糊的
相信一半你看到的，別信你聽到的
激勵：不能光靠比薩和啤酒
在日期上沉淪
2002年5月1日：“我們還開心嗎？分診的樂趣”
戰爭是地獄
這不是個人的事情
分診的5條黃金法則
魔鬼藏在細節裡面
很難進行下去，不是嗎？
謹小慎微
2004年12月1日：“向死亡進軍”
暗箭傷人
對失敗的連禱
轉折點
很少有人走過的路
2005年10月1日：“揭露真相”
遭受錯覺之苦
拿把叉子扎進我的身體
給我個坦率的回答
給豬抹口紅
看看所有這些傳言
我想知道真相
第2章 過程改進，沒有魔法
2002年9月2日：“六西格瑪？饒了我吧！”
啊！這是什麼巫術？！
召集騎兵
在混沌之外建立秩序
2004年10月1日：“精益：比帕斯雀牛肉還好”
任何事情都要適中
儉則不匱
過量生產
走向深處
運輸
多餘動作
等待
過程不當
庫存
缺陷
合作共生
2005年4月1日：“客戶不滿”
但願不知道
太過分，太遲了
敏捷錯覺
回退你的步伐
更多用武之地
使用正確的工具
布基膠帶和打包鋼絲
客戶滿意
2006年3月1日：“敏捷子彈”
真理的敵人
撥亂反正
準備改變了嗎？
讓他說話
你完善我
有點極端
準備玩橄欖球！
最後你要知道的
第3章 根除低下的效率
2001年7月1日：“遲到的規範書：生活現實或先天不足”
對於每次變更，攪動，攪動，攪動
走廊會議
委員會議
規範書變更請求
預防是最好的治療
2002年6月1日：“閒置人手”
寶寶做了件極壞的事情
告訴我該做什麼
儉則不匱
2004年6月1日：“我們開會的時候”
為什麼我們會在這裡？
我們正在試圖做什麼？
為什麼他們會在這裡？
為什麼我現在才聽到這個？
接下去要做什麼？
2006年7月1日：“停止寫規範書，跟功能小組呆在一起”
你失去理智了嗎？
在那裡進退兩難
特殊要求
我不記得了
堅持做一件事情
你準備好了嗎？
2007年2月1日：“糟糕的規範書：該指責誰？”
樹立靶子
溝通分解
保持簡單容易
變得穩健
獲取反饋
集成質量檢查
差別在哪？
第4章 跨越工種
2002年4月1日：“現代臨時夫婦？開發與測試”
我怎么愛你？讓我來數一下有多少種方式
必要的邪惡或珍貴的夥伴？
每個人都要知道自己的弱點
你完善我
2004年7月1日：“感覺性急——測試者的角色”
高級保護
改變一下對你有好處
黎明時分
充分利用數據
非常酷——我保證你
2005年5月1日：“模糊邏輯——君子之道”
包羅萬象
他們跟我們不一樣
通過安檢
著手去改變
更好地在一起
2005年11月1日：“廢除工種——有什麼理由搞專業化？”
歷經未來的日子
考察它的極限
足球是門科學
兩者之間的距離
你深陷其中
第5章 軟體質量不是夢
2002年3月1日：“你對你的安全放心嗎？”
小心晃動的鐘擺
做正確的事
安全受制於最薄弱環節
領導、跟隨或者離開
2002年11月1日：“牛肉在哪裡？為什麼我們要質量”
情況變了
足夠好還不行
艱難的選擇
終於有足夠的時間了
再檢查一遍
醫生，治好你自己的病
步步為營
太多疑問？
2004年4月1日：“軟體發展之路——從手工藝到工程”
工藝制桌子，工程造汽車
其實你知道
真實面對自己
數字的含義
各人有各人的習性
大處著想，小處著手
從優秀到卓越
2005年7月1日：“複審一下這個——審查”
糟糕的混合
完美風暴
誰來負責？
你有什麼想法？
正是這個形式
孩子，準備好了嗎？
再檢查一遍
神奇的匯總會議
審查的訣竅
走上正道
2006年10月1日：“對質量的大膽預測”
謎？我不這么認為
邪惡雙煞
嫌疑慣犯
你會喜歡它的
停止賣弄愚蠢
質量就是沒有意外
第6章 有時間就做軟體設計
2001年9月1日：“錯誤處理的災難”
恐怖，恐怖
使用異常
別丟棄，用上它！
2002年2月1日：“廚師太多燒不好菜——惟一權威”
一幅圖片抵得上一千個字
有人確切知道現在幾點了嗎？
只能有一個
萬物皆有聯繫
2004年5月1日：“通過設計解決”
如何才算足夠好？
設計完成
細節，細節
讓我看看你是由什麼組成的
當心缺口
成功處方
2006年2月1日：“質量的另一面——設計師和架構師”
你必須比那做得更好
改變一下對你有好處
他這么做不對
正確的做法
下一次，試試雕塑
關鍵要有正確的工具
打破這些壁壘
2006年8月1日：“美妙隔離——更好的設計”
分解難做
正確的做法
團隊不需要“我”
循序漸進
貓狗不分家
第7章 職業生涯歷險
2001年12月1日：“當熟練就是目標”
每個人都要知道自己的弱點
享其成但不坐等
我希望他們尊重我
我們都牽連其中
2002年10月1日：“生活是不公平的——考核曲線”
我不想再逆來順受了
知識就是力量
關注業務
前進，讓我快樂
伸出手去接觸某人
有了檸檬？製作檸檬水
改變你的主意
方向盤後面的人
2006年11月1日：“職業階段中的角色”
一個人同時扮演很多角色
搞清楚職業階段
我是有抱負的
資歷過高
我是特殊的
只能選一個
你想成為什麼？
2007年5月1日：“讓你自己與世界相連”
你認識的人
我利用習慣
難道你不好奇？
你得到了我們的感謝
我回頭再找你
歡迎來到這個世界
第8章 自我完善
2002年12月1日：“要么聽我的，要么走人——協商”
一個你無法拒絕的方式
逐漸長大
我腦子裡閃過的陰影和凶兆
不要傷害Messenger
皆大歡喜
2005年2月1日：“最好學會平衡生活”
平衡是關鍵
光說不練
我甚至不能平衡我的支票簿
平衡好，一切都好
2005年6月1日：“時間夠用了”
直接告訴我
免受打擾之苦
找到你的樂園
我們誰也不笨
我們必須共同承擔
告訴我必須做什麼
他還是個孩子
你應該休息一下
這裡秩序井然
坦誠相待
大有可為
2005年8月1日：“有理有節地控制你的上司”
我沒轍了
知彼知己
他們能自我適應
把水賣給魚
勢利的眼睛
付諸行動
敢於做夢
2006年4月1日：“你在跟我說話嗎？基本溝通”
為我著想一下
告訴我你想要什麼
你什麼時候想要？
縮小注意力跨度
就這樣完了？
2007年3月1日：“不只是開放和誠實”
那不是理由
我會對你誠實
那不容易
他們似乎有個開放政策
無處隱藏
跟我想的不一樣
走上正道
第9章 成為管理者，而不是邪惡的化身
2003年2月1日：“不只是數字——生產力”
小心你希望得到的東西
扮演一個角色
卓越開發者的素質
你要做法官
2004年9月1日：“面試流程之外”
抱怨得不到幫助
90%是準備
那就是問題
白板編譯器
幫招聘專員準備
再次幫面試官準備
友情提醒
最後的難題
2004年11月1日：“最難做的工作——績效不佳者”
你期望什麼？
知難而進
尋求專業援助
沒人想失敗
目標是成功
無所求，則無所獲
你不會總能如願
2005年9月1日：“隨波逐流——人才的保持和流動”
我只是想環球旅行
不錯的水壩？
像河水一樣流動
新鮮血液
分享就是關愛
成長空間
我必須要旅行
放任自流
2005年12月1日：“我能夠管理”
持續送出的贈品
優秀就夠了
草率行事
我想要工作
我不是東西
從優秀到卓越
我服務於人
2006年5月1日：“不恰當的比較——病態團隊”
想要挑起戰爭
這不是競爭
我會給你些提示
團結在一起
第10章 微軟，你會喜歡它的
2001年11月1日：“我是怎么學會停止焦慮並愛上重組的”
沿著巴別塔下來
地獄裡的生活
很少有人走過的路
容忍問題還是主動去解決？
2005年3月1日：“你的產品單元經理是個遊民嗎？”
有計畫的人
我等不及要去實施了
魔鬼藏在細節裡面
道路規則
回到正確的跑道上
2006年9月1日：“有幸成為Windows的主宰者”
你還有別的要求嗎？
準備輪船
設定路線
啟航
導航
責任
下一代Windows
2006年12月1日：“Google：嚴重的威脅還是糟糕的拼寫？”
他們步伐踉蹌，我們手舞足蹈
注定要失敗
聰明人需要智慧型客戶端
保持警惕
一馬當先
2007年4月1日：“中年危機”
你已經變了
日子照過，只不過要掌握一點竅門
不輕易冒險
我認為他們還不能勝任
不再年輕了
不要驚慌失措
沒有人是完美的
術語表
推薦序
讀者對I. M. Wright’s “Hard Code”欄目的喝彩
任何大型組織都有危險成為自身文化的犧牲品。關於世界應該是什麼樣子或者事情應該怎樣去做的神話，最後證明都是一個個自圓其說的預言。任何組織都會有這種傾向，但它對於需要不斷創新才能繁榮的技術公司來說，卻是個致命殺手。Eric Brechner做了件難以置信的事——他亮出了手術刀，深深地切入了組織內部看似無關緊要的東西。他毫不吝嗇地打出了重拳——偶爾也會故意玷污自己的名聲。儘管有一些隱語和例子對於微軟內部的員工更有吸引力，但他的智慧和至理名言，大都可以成為整個軟體行業的財富。
——Clemens Szyperski，首要架構師
“I. M. Wright”寫的關於開發時間表的文章真的是太棒了！它在我所屬部門參與的基礎設施項目上同樣適用。
——Ian Puttergill，部門經理
你沒有受到任何死亡威脅，是嗎？
——Tracey Meltzer，高級測試主管
這一定是個笑話——很坦率地說，這類純粹的謬論危機四伏。
——Chad Dellinger，企業架構師
Eric是我本人崇拜的英雄——很大程度上是因為他長期以來一直代表著開發社區的一種聲音。
——Chad Dellinger，企業架構師
軟體工程師很容易就會迷失在他們的代碼中，甚至更糟糕的是，他們迷失在過程中。那正是他們迫切需要Eric在“Hard Code”中提出的實用建議的時候。
——David Greenspoon，總經理
我剛剛讀完這個月的欄目……我不得不指出，這是我第一次認為你正在推行一個對公司完全錯誤並且帶有災難性的想法。
——David Greenspoon，總經理
Eric你真了不起 幾個月之前，我跟我的產品單元經理和一些開發主管恰恰進行過這樣的一次對話。
——Scott Cottrille，首要開發經理
我真的很喜歡這些欄目。它們是如此實用，而且還很全面！我喜歡它們的另外一個原因是，當我在指導初級開發人員的時候，我可以把這些欄目推薦給他們；他們也會記住這些欄目，因為它們都是那么地有趣。
——Malia Ansberry，高級軟體工程師
Eric，幹得好！我覺得你在這個欄目中說得非常中肯。我想，該給管理者傳遞這樣的信息，“不要害怕試驗。”事情的真實情況跟理想化的理論之間差別是非常大的。
——Bob Fries，合作夥伴開發經理
我只是想讓你知道我有多喜歡你寫的文字——它們充滿智慧、見解深刻，你還神奇地把本來很嚴肅的問題變得如此有趣（採用的方法很不錯）。
——Niels Hilmar Madsen，開發者傳教士
你那篇關於死亡行軍的欄目來的正是時候。我們正打算在未來幾周內開會討論功能削減的事情呢！那些我們以前付出很大代價才學到的教訓，不知怎么回事，總是輕易就被忘記了；你的欄目對大家起到了很好的提醒作用。
——Bruce Morgan，首要開發經理
我想讓你知道的是，我真的很喜歡並感謝你在EE站點上發表的所有文章。不過，直到今天，當我讀了“停止寫規範書”這個欄目之後，我不得不說，我強烈不同意你的觀點。
——Cheng Wei，項目經理
你到底是誰？你跟Eric Brechner都做了些什麼？
——Olof Hellman，軟體工程師
Eric，我剛剛讀完你寫的那篇叫“不恰當的比較”的文章。你不知道我有多感激你！你實際上把這個觀點傳達給了公司裡面成千上萬的人……你致力於正確領導和管理團隊，並把其中的奧秘跟大家分享，對於你的這種熱情我真的非常欣賞！
——Teresa Horgan，商務項目經理
前言
獻給當初對我說“為什麼不由你來寫？”的人：Bill Bowlus
你手上拿著的是一本關於最佳實務的書。它會比較乏味。但也許會比較有意義，你能從中得到知識，讀後甚至對你產生些許影響，但讀起來肯定還是乾巴巴而無趣的。為什麼這么說呢？
最佳實務的書是乏味的，因為這個“最佳”是跟具體的項目、具體的人、他們的目標以及偏好緊密相關的。一個實務是不是“最佳”，大家可能看法不一。作者必須把實務列舉出來讓讀者自己來選，並分析在什麼時候、因為什麼原因作出最佳選擇。雖然這種做法是現實的、負責任的，但也是令人厭煩的，最終無法取悅讀者。為釋疑而設計的案例研究會使文字有味一些，但作者仍必須把選擇的機會留給讀者，否則作者就會顯得傲慢、教條並且死板。
然而人們喜歡看到傲慢、教條、死板的學者之間的針鋒相對。大家喜歡引用學者們的觀點片段，與朋友和同事一起討論。為什麼不把這些最佳實務當作觀點欄來爭論呢？惟一的條件，就是要有人願意將自己扮演成一個思想保守的傻瓜。
本書的由來
2001年4月，在我歷經了Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics、Boeing等公司總共16年的職業程式設計師生涯，再在微軟做了6年的程式設計師和經理之後，我轉入了微軟內部的一個以在公司範圍內傳播最佳實務為職責的團隊。當時這個組正在運作發行名叫《Interface》月刊網路雜誌的一個項目。它很有意義，且富有知識性，但同樣也是乾巴巴而無趣的。我那時建議增加一個觀點欄目。
我的上司Bill Bowlus建議由我來寫。我拒絕了。作為一個半大孩子，我努力成為一個協調員，撮合多方產生成果。成為一個愛嘮叨的實務學者會毀掉我的名譽和效力。因此，我當時的想法是說服一個大家公認的小心眼的工程師來寫，他可能是我在微軟以前6年工作經歷中接觸過的一位固執的開發經理。
但Bill指出，我有22年的開發經驗，4年的開發管理經驗，寫作技巧也還行，而且有足夠的態度來做這件事。我只需要放下自身的心理包袱。另外，其他的開發經理都忙於常規的工作，不可能每個月來為我們寫觀點。最後Bill和我想出了一個用假名撰稿的點子，於是I M Wright的“Hard Code”欄目誕生了。
從2001年6月開始，我使用“I M Wright，微軟逍遙的開發經理”這個署名為微軟的開發者和他們的經理寫了49個“Hard Code”觀點欄。這些欄目的標籤行都打上了“絕對誠實，重拳出擊”的標語。每個月，成千上萬的微軟工程師和經理都在讀這些欄目。
前16個欄目在《Interface》內部網路雜誌上發表了。隨後同事（Mark Ashley和Liza White）給我分配了更多的主題。我和《Interface》的美工Todd Timmcke還一起製作了作者的很多搞怪照片。當網路雜誌停刊的時候，我才得以喘息的機會，但也停止了寫作。
14個月之後，在我們組的同事Amy Hamilton (Blair)、Dia Reeves、Linda Caputo、Shannon Evans和Marc Wilson的幫助下，我又開始在內部站點上發表我的欄目。去年11月份，我將所有的欄目轉移到了一個內部的SharePoint部落格上。
2007年春天，正當我打算休掉幾年前獎勵給我的假期的時候，我現在的經理Cedric Coco給了我在休假期間將“Hard Code”出版成書的授權。而微軟出版社的Ben Ryan也同意了。
除了我已經提及的人，我還想感謝《Interface》的其他成員（Susan Fario、Bruce Fenske、Ann Hoegemeier、John Spilker和John Swenson），其他幫助過本書出版的人（Suzanne Sowinska、Alex Blanton、Scott Berkun、Devon Musgrave和Valerie Wolley），支持我的管理層（Cedric Coco、Scott Charney和John Devaan），我現在的和以前的、複審過我的欄目並提出過很多主題的團隊成員（William Adams、Alan Auerbach、Adam Barr、Eric Bush、Scott Cheney、Jennifer Hamilton、Corey Ladas、David Norris、Bernie Thompson、James Waletzky、Don Willits和Mitch Wyle），我才華出眾的中學英語老師（Alan Shapiro），以及那些慷慨給予我反饋的讀者們。特別地，我還要感謝我的妻子Karen和我的兒子Alex和Peter，他們讓我做任何事情都充滿信心。
本書的讀者
組成本書的49個觀點欄最初是寫給微軟的開發者和他們的經理看的，儘管它們也是我過去在軟體行業6個不同的公司、28年的工作經驗中提煉出來的。編輯和我一起修正了表達語言，註解了那些微軟內部的特殊用語，使得本書適合於所有軟體工程師和工程經理閱讀。
我在這些欄目中表達的觀點是我個人的，不代表我現在和以前任職過的任何一家公司，包括微軟。我在欄目中的註解以及本簡介中的言論同樣都是我個人的，與公司無關。
本書的組織方式
根據主題的不同，我把所有欄目分成了10個章節。前6章剖析了軟體開發流程，接下來3章重點討論人的問題，最後1章批判軟體業務運轉方式。用於解決這些問題的工具、技巧和建議遍布全書。本書的最後還附有術語表和索引方便大家參
每一章的各個欄目均按照當初在微軟內部發表的時間順序排列。每章開頭我都給出了一個簡短的介紹，隨後就是當初我以I M Wright名義發表的欄目內容。編輯成書的時候，我還適時在欄目中加上了“作者注”，以解釋微軟的術語，提供更新內容或者額外的背景知識。
編輯和我盡力保持了原有欄目的完整性。我們做的，僅僅是糾正語法和內部引用。稱得上改動的其實只有一處：就是將原來一個叫“你被解僱了”的欄目標題改成了“最艱難的工作”，因為以前那個標題太容易讓人誤解了。
每個欄目都以一段激昂的演說開場，然後就是問題根源的分析，最後以我對這個問題如何改善的建議結束。我酷愛文字遊戲、頭韻和通俗文化，因此欄目中充斥著對這些東西的引用。特別是大部分欄目的標題和副標題都直接取材於歌詞、電影對白和有名的諺語。是的，我自娛自樂，但撰寫這些欄目確實給我帶來了些許樂趣以及痛快的宣洩。希望你也會喜歡！
系統要求
本書提供的工具都是微軟的Office Excel 2003和Office Word 2003格式的。只要你的電腦上安裝有Word和Excel的瀏覽器，你就能使用這些檔案。
微軟的組織結構
因為這些欄目最初是寫給微軟的內部員工看的，因此簡要了解一下微軟以及我在工作中扮演的角色會有助於更好地理解這些文字。
目前，微軟的產品開發分成三大業務部門，總共有大概25條產品線，超過450個產品單元，和眾多的功能團隊。這些部門是平台產品與服務部門、微軟商業部門、娛樂與設備部門。部門內的產品線是由相關的產品套件整合在一起形成的，比如Office System和Visual Studio。
每條產品線包含了大約20個獨立的產品單元。通常情況下，這些產品單元共享原始碼控制、建造、安裝、工作條款跟蹤和項目協調，包括價值主張、里程碑安排、發布管理和工程支持。除了這些協調服務之外，產品單元還有高度的自主權，可以對產品、流程和人員作出自己的安排。
一個典型的產品單元通常有一個產品單元經理（PUM，Product Unit Manager）和三個工程工種經理：部門項目經理（GPM，Group Program Manager）、開發經理（Development Manager）和測試經理（Test Manager）。其他工程工種，比如用戶體驗、內容發布（比如線上幫助）、實施，可能單獨對某個產品單元負責，也可能在產品線或者整個部門中共享。
每個工種都要抽出一個或多個代表，以組成一個叫功能團隊的虛擬組織，來開發具體的產品功能。這些人的工作仍然匯報給各自的工種經理。有些功能團隊選擇敏捷方法，有些喜歡精益模型，有些採用傳統的軟體工程模型，有些則根據實際情況混合了上述多種方法。
微軟怎么能包容所有這些多樣性和產品的區域自治、還能為朝著一個共同的目標有效地工作呢？這就要靠產品線公共的項目協調了。舉例來說，產品線的價值主張為所有的產品單元和他們的功能團隊設定並統一關鍵套用範例、質量尺度和框架體系。
為了促進跨部門和產品線的協調和共享，特別是為提高質量和效率，微軟還設立了一個組織叫Microsoft Trustworthy Computing and Excellence。它是我的上級組織。具體來說，我的工作職責是，要讓微軟全球超過1萬名的開發者在構建令人興奮的、高質量的用戶體驗時，能夠做得更加開心、更富有效力。不用說，這是一項長期的工作。
我的團隊每月將開發部門的領導層聚集在一起，談論問題並指導我們的工作。我們研究公司範圍內乃至整個行業內的工程方法，以期找到新的機會和領域去提高。我們通過網路共享工具、最佳實務，以及實施職業生涯指導。我們舉辦各種活動和獎項評比，與各種團隊商討，為開發中的各個級別、各種角色提供技術培訓。非常棒的工作！另外，我每月還在寫著觀點欄。
書摘
第1章 項目的不當管理
本章內容：
2001年6月1日：“開發時間表、飛豬和其他幻想”
2001年10月1日：“竭盡所能：再論開發時間表”
2002年5月1日：“我們還開心嗎？分診的樂趣”
2004年12月1日：“向死亡進軍”
2005年10月1日：“揭露真相”
我的第一個欄目是在2001年6月刊的微軟內部網路雜誌《Interface》上發表的。為了進入I M Wright的人物角色，我需要一個真正能讓我傷腦筋的主題。而工作的時間安排和進度跟蹤再好不過了。
項目管理的偉大神話至今都讓我瘋狂，它的威力遠勝過其他任何主題。這些神話是：
1 人們能夠按期交付被要求實現的功能（事實上，項目可以按期交付，但人們按期交付功能的機率不會高於擊中曲棍球的機率）。
2 有經驗的人估計日期比較準（事實上，他們能夠較好地估計工作，但不是日期）
3 人們必須按照項目預定的日期按時交付項目（事實上，因為人們不能按期交付被要求實現的功能，而你若想你的項目能夠按期交付的話，你必須進行管理風險、範圍和通過溝通來減輕人性的弱點可能給項目帶來的負面影響）。
在本章中，I M Wright討論了如何通過管理風險、範圍和進行溝通，來保障你的項目能夠按時完成。前兩個欄目專門討論開發工作的時間安排，接著討論善後事宜的管理（我們稱之為“Bu9分診”），最後是一篇對死亡行軍的聲討，以及一個關於人們為什麼要撒謊的哲學欄目。
不得不提的是：通過我在微軟多年的工作經歷，以及對我所在組織的觀察，我發現，項目管理行為和方法在不同規模和抽象層次的組織中，其表現大不相同。這些層次包括：團隊或功能層次（10人左右），項目層次（50～5000人，他們一起致力於某個特定的產品發布），以及產品層次（由高層人員主管的多次產品發布）。敏捷方法在團隊這個層次能夠很好地發揮作用，組織方法在項目這個層次比較適用，而長遠的戰略規劃方法在產品這個層次功效顯著。然而，一個人幾乎不可能同時在多個層次上工作。時間長河為每個人將這些經歷錯開了。當一個人從一個層次轉到另一個層次工作的時候，他可能會想，在以前那個層次上有效的方法在其他層次上應該也同樣有效。災難就這么產生了！原因很簡單：小型、緊湊的群體跟大型、鬆散的機構在運轉方式上是不同的。因此要因地制宜，選擇最適合的方法。
2001年6月1日：“開發時間表、飛豬和其他幻想”
一匹馬走進酒吧，說道：“我能在兩天內完成那個功能。”開發成本計算和時問安排是個玩笑。相信它的人，要么是傻瓜，要么是初出茅廬的項目經理。這不是模糊科學，純粹是杜撰。不錯，的確有人相信編碼可以被分割成一個可預見進度和質量的可重複的過程，那我兒子至今還相信牙仙子呢！事實上，除非你只需編寫10行那么長的代碼，或者代碼可以直接從以前的工作中複製過來，否則你不可能知道編碼會花費你多久時間。
作者註：項目經理（Program Manager，PM）有很多職責，其中最主要的是負責說明最終用戶體驗和跟蹤項目的整體進度。這種角色是必要的，但他們常常不討開發者的喜歡，因而也很少得到開發者的尊重。真遺憾，項目經理是一份很難做好的工作。但是，對於Wright先生來說，做好項目經理仍然是一個有趣並且容易達到的目標。
芮氏規模估計
當然，你可以估計，但估計出來的時間是成對數比例的。有些事情需要花費幾個月，有些事情需要幾周，有些需要幾天，有些需要幾個小時，有些則只需幾分鐘。而我跟我的部門項目經理（Group Program Manager，GPM）一起給一個項目做時間安排時，我們對每個功能使用“困難／中等／容易”3個等級來評估。“困難”意味著一個全職開發人員需要花費整個裡程碑時間；“中等”意味著一個全職開發人員需要花費2～3周時間；“容易”意味著一個全職開發人員需要花費2～3天時間。這裡沒有中間等級，也不做精確的時間表。為什麼呢？因為我們倆知道，我們已經不可能知道得再精確了。
媒體評論
專家評價：
“我能肯定，I M Wright不會聽我的話，試都不用試。”
——Jon DeVaan，微軟公司高級副總裁
“儘管我絕不會從這傢伙手裡買二手車，但在軟體開發方面，他確實也對他自己的東西知道得一清二楚。”
——Ian Ellison-Taylor，微軟公司工程部總經理
“微軟公司內部所有工程師的必讀之書。”
——Peter Isensee，微軟公司開發經理
揭示關於編碼、測試和項目管理的殘酷現實——一位微軟的內部人士如實地向你述說。I M Wright的“Hard Code”故意煽情，幾年來在微軟內部成千上萬的工程師之間引起了激烈的爭論。現在（也顧不上“家醜不外揚”了），我們把他的觀點向所有人公開。
本書收錄了49個欄目。Eric Brechner重拳出擊，對最令他苦惱的問題提出了最佳實踐的解決方案，另外還加上了他坦誠的註解。他解剖了開發過程，審查了棘手的團隊問題，批判了軟體業務的運轉方式——自始至終充斥著機靈的幽默和譏諷的風趣。他的想法並不總是很受歡迎（他也不關心那個），但它們的的確確激發起了人們的討論和想像，推動著軟體相關的活動走向卓越。
讀者評價：
讀者對I M Wright’s “Hard Code”欄目的喝彩
任何大型組織都有危險成為自身文化的犧牲品。關於世界應該是什麼樣子或者事情應該怎樣去做的神話，最後證明都是一個個自圓其說的預言。任何組織都會有這種傾向，但它對於需要不斷創新才能繁榮的技術公司來說，卻是個致命殺手。Eric Brechner做了件難以置信的事——他亮出了手術刀，深深地切入了組織內部看似無關緊要的東西。他毫不吝嗇地打出了重拳——偶爾也會故意玷污自己的名聲。儘管有一些隱語和例子對於微軟內部的員工更有吸引力，但他的智慧和至理名言，大都可以成為整個軟體行業的財富。
——Clemens Szyperski，首要架構師
“I M Wright”寫的關於開發時間表的文章真的是太棒了！它在我所屬部門參與的基礎設施項目上同樣適用。
——Ian Puttergill，部門經理
你沒有受到任何死亡威脅，是嗎？
——Tracey Meltzer，高級測試主管
這一定是個笑話——很坦率地說，這類純粹的謬論危機四伏。
