今天把這本書看完了，節錄一些我覺得不錯的片段下來
1. 在很多程式開發組織中，出現設計爭議時，總沒有人願意做出決策(
通常都是因為一些「政治理由」)，所以開發人員只去做那些沒有爭議的項目。
2. 當你和整組人一起建立產品時，通常每個人都會各有所好，因而產生各式各樣真正或虛構的必備心愛功能，如果要將這些功能全部都做出來，恐怕永遠做不完而且要花很多很多的錢。所以你必須馬上開始刪功能，而刪功能的最佳方法就是利用規格的「非目標」章節，
列出我們不打算做的東西。
3. 1980年代當微軟開始快速成長時，那裡每個人都讀過The Mythical Man-Month(人月神話，這本中文版出很久了)這本軟體管理經典。這本書的主要重點是說，
在進度落後的專案中增加更多程式員，只會讓進度更加落後。這是因為當團體中有n個程式師時，溝通路徑的數量會變成n(n-1)/2，也就是以O(n^2)增加。
4.
不要把程式員升為程式經理。良好程式經理所需的技能(撰寫清楚的文章，外交手腕，對市場的察覺，對使用者的認同以及良好的使用介面設計)幾乎都不是良好程式員所需的。當然有人兩者都行，不過少之又少。
5.
別讓程式人員對程式經理報告。這是很微妙的錯誤。我在微軟當程式經理時設計了Excel的Visual Basic(VBA)策略，並且訂出涵蓋最微小細節的完整規格，詳細敘述應該如何在Excel裡實作VBA。我的規格大約有500頁。在Excel 5.0開發的巔峰時期，我估計每天早上有250人來上班，主要任務就是要實作我寫的這份龐大規格。我完全不知道這些人是誰，不過Visual Basic組就有十幾個人光是在寫這玩意的文件(更不用提寫Excel的文件或是全職負責說明檔內超連結的人了)。不過最誇張的是我位在這層層結構的「底層」。沒錯。沒有人要向我報告。如果想讓大家去做某件事，我必須說服他們這件事該做。當主開發師Ben Waldman不想做我規格定義的某個項目，他跳過不做就好了。當測試人員報怨規格中某個項目不可能做完整的測試，我就得去把這個項目簡化。
如果這些人得向我報告，產品可能不會這麼好。...
凝聚共識的決策型式卻是做對事的最好方法。
6. 當你一直往上把事情弄得太抽象，就會像上太空一樣沒有氧氣。有時候這些聰明的思想家就是停不下來，然後就創造出這些荒唐又無所不包的高層次宇宙景像，這些東西什麼都好，就是完全沒有實際的意義。
這種人我稱之為架構太空人。要他們寫程式或設計程式是難上更難，因為他們沒法子不想架構。叫太空人是因為他們活在氧氣層之上，我不知道這些人是怎麼呼吸的。他們通常
在真正的大公司上班，只要這種公司才養得起大批不事生產，完全沒有貢獻的高學歷份子。
7. Alfie Kohn在哈佛商業評論中一篇已成為經典的文章中寫道：
過去三十年間至少有兩打以上的研究明確地指出，為了報酬而工作的人，表現不如完全不期望有報酬的人。
他的結論是
「激勵(或者說賄賂)在職場上是行不通的」。DeMarco和Lister更進一步明白地表示，任何型式的職場競爭及獎懲方案，包括以前流行那種「在某人做對事時馬上獎勵」的把戲，所帶來的傷害都大過好處。
給某些人正面激勵 (比如愚蠢的公開頒獎儀式)暗示他們其實只是為了拿那個壓克力獎牌才有表現；也暗示他們在工作上不夠獨立，要有甜頭才會努力；這實在是既侮辱又貶低人格。
8.
QA的主管應該有否定權，可以阻止發行不合格的軟體。
9. 就個人層次來說，你曾經注意過某件事嗎？叫某人做一個工作可以做得很好，可是如果給他兩個工作，他會把其中一個做好卻忽略另一個，不然就是兩件工作都做得很慢，慢到你覺得懶鬼都比他勤勞。這是因為
程式設計的工作就是需要很長的切換時間。
10. Netscape 6.0第一個公開的beta版終於出來了。5.0版從來沒出現過，最後一版重大改版是大約三年前發行的4.0版。在Internet世界裡三年的時間長得
可怕。就在這段時間中，Netscape只能無望地坐看市場佔有率直線下降。...他們做了一個每家軟體公司都可能犯的
一個最糟的策略錯誤：
他們決定把
程式從頭重寫過。
11.
讀程式比寫程式困難
12. 新程式碼比舊程式碼好的想法顯然是很荒唐的。舊程式碼已經被
用過也被測試
過。很多問題都已被找出來並被修好。它並沒有什麼問題，不會因為在你的硬碟裡放久了就生出新的問題。...當你把程式碼丟掉從頭重寫時，其實是把這
所有的知識都丟掉了。這所有已修正的問題，好幾年的寫程式的成果。...你會
讓出市場領導地位。你會
把兩三年的時間當禮物送給競爭者。相信我，軟體的一年可是很長的。...你會讓自己陷入一個極端危險的位置，到時候會有很多年都只能發行舊版程式，完全無法因應市場需求的新功能而改變策略，因為你沒有可以發行的程式。這段時期最好還是把公司收起來算了。...你會
浪費大量的資金去撰寫已有的程式。
13. 你一定要記住，在要從頭重新開始時，
完全沒有理由相信這次會做得比第一次好。首先你的程式團隊根本不可能和當初相同，所以並不會真的有「更多的經驗」。你其實只會把大部份的舊錯重新再犯一次，另外再多加一些舊版本沒有的新問題。
這本書實在是太精采了，一堆名言，下篇待續。
