這是人月神話：軟體專案管理之道（20週年紀念版）的第十九章：《人月神話》二十年(The Mythical Man-Month after 20 Years)，這一本書真的很舊了，但是作者一直要表達的是這裡頭的概念還是可用的。
但是開場白『I know no way of judging the future but by the past.- PATRICK HENRY（除了根據過去的經驗，我不知道還有什麼方法能夠預測未來）
You can never plan the future by the past.- EDMUND BURKE（你永遠無法憑過去的經驗來計畫未來）』，所以呢？過去經驗不能夠預測未來，但是人們又不得不用過去經驗來預測未來，這結果有時很順利，有時我們只能謝天了，有時可能得要怨天，真是世事難料。
這本書的中心理念：概念整體性(conceptual integrity)與架構設計師(architect)
概念整體性 『一個井然有序、優雅的軟體產品所展現給每一位使用者的，無論是在應用上、在執行這項應用的策略上、在使用者介面指定動作和參數的手法上，都必須是前後連慣的一套心智模式(mental model)。』
架構設計師 『將某些不可分割的智能創作交付給產品的架構設計師來完成，產品在任何方面，只要是使用者能感受得到的，都是由他來負責概念上的整體性。』
將架構獨立於實作(implementation)和實現(realization)之外
架構設計師工作的再細分
今天我比以往更加堅信不移
第二系統效應：過度設計與頻率猜測
為廣大的使用者群來進行設計
功能過度膨脹 裡頭講到了Word 6.0的速度緩慢，這是事實，但是微軟為什麼還一直開發Windows 7還不終止，還要繼續開發下一代？為什麼Office 到了2011年之後，搞不好還有下一代喔，這功能是不是過度膨脹了？
定義使用者群 調查需求似乎是一門科學了，在這裡有強烈感覺。
頻率 這裡頭作者看起來傾向於猜測的使用，但是也提到了Jeff Conklin發展的gIBIS，ㄚ琪索性就查了一下gIBIS(graphical Issue Based Information System)，中文譯作議題導向的資訊系統，它是指一個特定應用
的超文件系統（application-specific hypertext system），它通常會被使用在大型而且複雜的問題討論上，並且支援團體或小組的互相溝通。看起來是透過溝通的管道在針對問題做解決，我並不清楚這個的應用，但是作者說那是非常有用的，不過還是強調『錯誤而明確，也遠比模糊不清要好』，看來錯也要錯得有理才是。
另外The Introduction of The Second-System Effect裡有提到第二系統效應，有位學生也提到The Introduction of Plan to Throw One Away裡的第二個版本，中文的感覺不會是一樣的，但是在英文原文裡，可能是一樣，所以導致有這個問題的提出，我只能說這個學生看得很認真，作者也承認他很會唬爛。
WIMP介面的成功
所謂的WIMP就是視窗(Windows)、圖示(Icon)、選單(Menu)、點選(Pointing)介面，蘋果麥金塔是最先實現這個概念的。
透過隱喻來達成概念整體性
命令的表達與雙游標的問題
一個卓越的解決方案
進階使用方式與便利性
逐步從新手轉換到進階使用者
成功地把直接融入當做是強化架構的策略
WIMP的命運：終將落伍 呵呵，這麼早就在預言這件事了，但是不知微軟為何到現在還一直在升級中？
不要建構出必然失敗的系統 — 瀑布模型是錯的！
The Introduction of Plan to Throw One Away這一章似乎在現代不怎麼適合研讀，虧ㄚ琪還花了這麼多的時間去讀，作者說明這裡頭用到一個錯誤的假設，瀑布模型，因為這個模型的根本錯誤，『就是假設專案只會從頭到尾將過程流過一遍，架構很棒、很好用，實作的設計很正確，而實現階段的錯誤也都可以在進行測試的時候加以修正。』這裡頭錯就錯在錯誤是發生在實現階段，這與實際的狀況不符。
第二個錯誤，『就是假設人們可以一次件夠出整個系統，能在所有的實作設計、大部分的程式編寫、許多的模組測試都完成之後，結合所有的程式片段來進行整合性的系統測試。』
逆流而上是必須的 聽這一句話似乎簡單，但是相對的也代表要辛苦去做，刻苦銘心的體驗是必須的，這時候你還想偷懶嗎？看起來要翹腳看報紙是不可能的。
較佳的漸進式開發模型 — 逐步細分精製
建構出首尾相連的骨幹系統
Parnas的家族系列產品概念
微軟的「每晚重新編譯」方案 這不就跟約耳的Knowledge Gained by Daily Builds Are Your Friend，不知道約耳的這個習慣是否來自微軟，不過感覺好像。
漸進式開發與快速原型製作 裡頭提到一種綠野仙蹤(Wizard of Oz experiment)，看起來是滿有趣的，有空再來深入。
關於資訊隱藏，我錯，Parnas才對
這在The Introduction of Propositions of the Mythical Man-Month: True or False？已經有分享過，不過這裡作者再次強調『當今慣常以物件導向程式設計(object-oriented programming)來落實的資訊隱藏是提升軟體設計層次的唯一方法。』所以我想是由贊同Harlan Mills的主張轉向Parnas吧，而Parnas的模組資訊隱藏可說是物件導向程式設計理念的鼻祖。另外一些思想家把Parnas的模組改良成抽象資料型別(abstract data type)，以此衍生出多物件。還有就是具威力的繼承(inheritance)觀念。物件導向程式設計已經在The Introduction of No Silver Bullet – Essence and Accident in Software Engineering及The Introduction of “No Silver Bullet”Refired分享過，各位可以再看看。
人月有多麼像神話？Boehm提出的模型和數據
作者用Barry Boehm的著作Software Engineering Economics來紮實地證實《人月神話》的主張，亦即人力與工時之間的取捨根本不是線性的關係，這裡有從維基引用來的資料：
『
T = k * (SLOC)(1 + x)
For a single software developer, k can be factored out by using more than 1 SLOC data point. In this case, x can be a fraction like 0.1 or 0.25.
- Note: since man-years are not interchangeable with years, Brooks’ Law applies:
- Adding programmers to a late project makes it later.
- Thus this formula is best applied to stable software development teams which have completed multiple projects.
』
維基裡面竟然還有Brooks的定律，哇！
難怪作者再次強調，Brooks定律有多準確？在Abdel-Hamid和Madnick的《Software Project Dynamics: An Integrated Approach》提到Brooks的定律，看來很多人已經把Brooks定律神化了。
Stutzke也有一套簡單的模型來印證這個定律。
人就是一切（好吧！幾乎是一切）
同意，沒意見。
用人的智慧 作者在這裡推薦這本書Peopleware： 腦力密集產業的人才管理之道 Peopleware: Productive Projects and Teams, 2nd ed.這一系列的文章分享請見Peopleware: Productive Projects and Teams。
專案轉移 由作者的經驗來看，很少有成功的。
放棄權力的威力
另外這一本Small Is Beautiful: Economics As If People Mattered提出一個組織企業的理論，可以讓勞工激發出最多的創意和樂趣，這到是很令人嚮往去看不是嗎？希望有中譯本的。
在教宗碧岳十一世的《四十年》通論（Encyclical Quadragesimo Anno)中提到的「輔助功能原則」，看起來小企業有它可以生存的地方，雖然作者也在觀察這些被大企業併購的小企業的後續情形，但是我們確實看到很多這樣的企業模式在我們的周遭中，而台灣有名的中小企業模式，還會有嗎？我很期待…
最大的驚奇是什麼？電腦大量普及
微電腦革命改變了每個人使用電腦的方式 過去可能還提到老人加布會用電腦，但是現在ㄚ琪知道的連九十多歲的老人家也會用電腦了，真是令人驚訝。有了電腦很多的創作都大大地改變了，這種創意真的是多到無法細述。
微電腦革命改變了每個人開發軟體的方式 WIMP的介面模式真的是一個大影響。
全新的軟體產業 – 套裝軟體
傳統軟體產業：
電腦供應商
應用軟體使用者
客製化應用軟體的開發者
商業套裝軟體的開發者
套裝軟體產業
外購與自製 — 套裝軟體組件
中介程式設計 『開發Hypercard stack、Excel範本或MiniCad這類的函式，有時稱為中介程式設計(metaprogramming)，也就是為套裝軟體的某一小部份特定的顧客群而新打造出來的一層量身定做的函式。』真沒想到ㄚ琪一直沒有介入的市場，竟然在這裡會被提到，看起來有需要在這個地方成長了，特別是如果要在一般使用套裝軟體的企業，像是用微軟的軟體，有了這個專長，真的是可以為以後的工作加分不少。
這才是真正切入本質的行動
所以，需要的是什麼？ 確認出四個階層的套裝軟體使用者：
- 一般使用者
中介程式設計師
外部通能創作者，這個倒是很像ㄚ琪目前的工作形式，這裡面有些技術我還沒聽過，像是攔截命令(intercepted command)、回呼函式(callback)、多載函式(overloaded function)等等。 - 也是中介程式設計師，運用一個或特別幾個應用軟體，以之作為更大型系統裡的組件，或許以後會有這一類工作的需求。
-
軟體工程的現況與未來
-
這裡頭作者把化學工程跟軟體工程做比喻，很有趣或許可以拿來做下一步軟體工程的預測，但前提你可能得對化學工程瞭解才行。
-
這一章很像是多年之後再次review的著作，所以很長，有些ㄚ琪也無法一一詳述或瞭解的，但是總是有些受用真是不錯。
-
在後記裡，ㄚ琪一定要引用這一句『人類的所為其實很渺小，一切都源自於上帝賜予人們充實精神糧食的權利，因而為了狂熱，每個人擁有樂於追求的自由，我滿心感激』，真的是讓人感動，Brooks的謙卑，以及真正瞭解這所有的一切來自與神，最近又為了贖罪與悔改的能力擴大，我不禁喜悅，這真的很美好。