THE MYTHICAL MAN-MONTH | 工作達人(Job Da Ren)

Archive for the ‘THE MYTHICAL MAN-MONTH’ Category

The Introduction of The Mythical Man-Month after 20 Years

2011-06-01,Last modified: 2011-05-31Please wait

這是人月神話：軟體專案管理之道（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的謙卑，以及真正瞭解這所有的一切來自與神，最近又為了贖罪與悔改的能力擴大，我不禁喜悅，這真的很美好。

Tags: Boehm, Software Engineering Economics, THE MYTHICAL MAN-MONTH, WIMP, 中介程式設計師, 人就是一切, 人月神話, 套裝軟體, 漸進式開發模型, 瀑布模型, 第二系統效應, 編譯, 資訊隱藏, 電腦大量普及
Posted in THE MYTHICAL MAN-MONTH | No Comments »

The Introduction of Propositions of the Mythical Man-Month: True or False？

2011-05-27,Last modified: 2011-05-25Please wait

這是人月神話：軟體專案管理之道（20週年紀念版）的第十八章：《人月神話》的主張：是真是假？(Propositions of the Mythical Man-Month: True or False？)，這裡的開場白是這樣的『別管別人懂不懂我們的意思，簡單扼要都非常好』(For brevity is very good, where we are, or are not understood.)，這一章是在跟1975的出版做比較，感覺有點在做總複習吧，如果之前ㄚ琪已經有提到了，我就不再贅述，如果有新鮮的點子，那我就再多說一點好了。

在The Introduction of The Tar Pit這一節裡，ㄚ琪應該要多補充這個行業工作的苦難：

將做事態度調整到追求完美，是學習軟體工程的最困難部分
由其他人來設定目標，並且必須依靠自己無法控制的事物（特別是程式）；權威不等同於責任
實際情況看起來要比這更糟：真正的權力來自於每次工作的完成
任何創造性活動都伴隨著枯燥耗時的辛勤工作，建構程式也不例外
人們通常期望專案在接近結束時，（bug、工作時間）能進展得快一些，然而軟體專案的情況卻是越接近完成，進展得越慢
產品在即將完成時總面臨著陳舊過時的威脅

後面的描述ㄚ琪覺得，還可更加地延伸到我們人所學得軟體技術，也會很快地過時，你若是要投入這一行，持續地追求新知有可能是必要的。

在 The Introduction of The Surgical Team這一節裡，ㄚ琪注意到作者所說的上帝對婚姻的設計，看來兩個人的團隊是最好的組合，神的大智竟然可以應用在軟體工程上，當你在學福音的時候你會注意到這點嗎？

在The Introduction of Why Did the Tower of Babel Fail?這一節裡，有關團隊成員跟工作手冊的關係，『每一位團隊成員都應該看到〔工作手冊〕全步的文件內容』，現在作者改口為『每一位團隊成員都應該可以看到全部的文件內容，也就是說，全球廣域網路(World-Wide Web)的網頁應該可以滿足需要』，那時網路似乎還滿起飛，現在看起來讓作者改口了，這個技術真是讚啊。

另外我忘記提到一個關鍵，持續更新內容，不管是在工作手冊上，或是在網站或部落格上，持續更新是王道，再學習福音上，持守到底才是成功。

David Parnas的一個絕招，『所有人都要看完所有東西的目標真是大錯特錯，有部份應該被封裝(encapsulated)起來才對，不是屬於你的東西，就不必也不被允許去看裡頭的細節，你只應該看到介面』，這一點是作者激推的。

在The Introduction of Ten Pounds in a Five-Pound Sack這裡，ㄚ琪有提過硬體的便宜，作者已經改變暫存區域的使用原則了，看來見解相同。

另外作者提到一個落伍的觀念『程式庫裡的每一個組件都應該包含兩套程式碼，一套是執行速度最快的，一套是使用空間最少的。』之前看起來不覺有什麼不對，但現在有點感覺了。

在The Introduction of The Documentary Hypothesis這節裡，這點『關鍵文件的相當於提供了一個監督和預警的機制。』這點ㄚ琪也漏掉了，補充之。

在The Introduction of The Whole and the Parts這節ㄚ琪漏掉了Vysotsky的話『有太多太多的失敗都源自於自始至終都搞不清楚要做的是什麼東西。』

漏掉了這些將可補足ㄚ琪對這本書的研讀與瞭解，這一本真是經典。

Tags: THE MYTHICAL MAN-MONTH, 人月神話
Posted in THE MYTHICAL MAN-MONTH | No Comments »

The Introduction of Aristocracy, Democracy, and System Design

2011-01-23,Last modified: 2011-05-24Please wait

這是人月神話：軟體專案管理之道（20週年紀念版）的第四章：專制、民主與系統設計，在The Introduction of The Surgical Team有提到概念整體性的問題，文章之前展示蘭斯主教座堂跟其他教堂的不同處，來說明系統設計應該保有概念整體性(conceptual integrity)。

達成概念整體性

『只有當功能增強所節省下來的時間超過學習、記憶和查閱手冊所耗費的時間，電腦的使用便利性(ease of use)才會提昇，以現代軟體工程來說，這方面的確是獲益大於所付出的成本，但最近幾年，似乎是複雜的功能越加越多，而獲益成本比(ratio of gain to cost)卻隨之越低。』這真的是如此，電子產品功能太多不見得是好事，我妹的朋友就因此把新買的HTC手機讓給我用，因為他連電腦都不太會用，導致他買了智慧型手機之後，竟然不會用，有時人會為趕流行買下新奇的東西，但是如果不夠便利使用的話，很快地在垃圾桶中找到它。

『由於目的是使用便利性，所以功能概念複雜度比(ratio of function to conceptual complexity)才是系統設計的最終測試標準，好的設計既不可單獨偏重功能性，也不可偏重簡單性。』

這個功能概念複雜度比術語看起來就很複雜，我不知是否有計算公式可以計算，但是正如作者說的，就是要兼顧功能性、便利性、簡單性(simplicity)，所以簡單地講就是要直接(straightforwardness)，就像我從我妹朋友拿來這隻HTC Touch Diamond來說好了，它的外觀很炫很酷，操作也很像Windows，就手機的功能使用來說也很多，可以就簡單性來說，我覺得比不上Nokia的，使用也不夠直接，常常一個功能不知到哪找，害我去日本還不能導航，迷路浪費了不少時間，真是令人嘔！

專制與民主

『要達成概念整體性，換句話說，這意味設計必須出自於一個人的想法，或是極少數人的一致決定。

然而，時程的壓力卻迫使系統的開發工作必須由更多人來一起合作，有兩個技術可以用來解決這兩難的問題。第一個是小心地把工作切分成架構(architecture)與實作(implementation)兩部份，第二個就是上一章所提到的外科手術團隊。…這裡的架構指的是使用者介面完整而詳細的規格。…實作是講如何具體實現(realization)』，比如最近我接了一個案子，一個部門的主管要我將別的部門的交接簿拿來用，請我幫他做，但是我因為另一個部門的伺服器環境的不同，不想照抄他的程式碼，而且我也不想破壞這個主管原有的習慣性，所以我照抄他的架構，也就是介面的部份，但是我在實作時，已經把他把所有的程式語言都改掉了，但是使用者卻感覺不出差異來，接著我就可以繼續擴展我的程式功能，如此我才可以繼續在這一家公司待下去。

這裡所說的專制與民主，就好像架構與實作，看起來好像要專制一點，而架構因此看起來就比較重要，所以相形之下架構設計師好像比較偉大，但是作者還是有反駁，說『實作上的設計工作跟制定外部規格(external specification)相比，不見得就是沒有創意的工作，只是發揮創意的類型不同罷了』，看到讓ㄚ琪好像稍微寬心一點了，看起來還是有揮灑的空間。而且實際上，『產品的成本效能比(cost-performance ratio)是非常仰賴實作人員才能夠提昇的，這跟使用便利性得仰賴架構設計師的道理一樣的。』

約束對藝術而言是件好事 (discipline is good for art)這個不知是哪裡的典故，但是dejavu這樣說『當我們常常在抱怨，生活有太多的限制，使我們無法充分的發揮專長時，是否有想過。出名的藝術家，總是在嚴苛的環境中，製作了永垂不朽的名作。過去的我曾經天真的以為，不朽的生命可以為世界帶來進步。但慢慢地，我體悟到，一個人的成就不在於生命的長短。反而容易因為生命的無止盡，使得我們終日怠惰、荒廢。印象中曾經有一個（或許不止一個）漫畫家，將未來（人類擁有幾乎無止盡的生命）描繪成一個地獄，因為生命可以隨意製造，所以人類再也不尊重生命了。』這樣子的想法對比於『形式就是解放(form is liberating)』，看起來也是對比的，善與惡、對與錯、黑與白這種對比的概念，一定讓人很頭痛，就連孔子講得中庸，我看就更難了，所以怎樣拿捏，我看到這裡，還沒搞清楚，所以就繼續看吧！

在架構完成之前，實作人員要做些什麼？

看起來好像沒事可做，因為如果架構沒有先完成，由實作人員來先做專案那麼會發生很多災難，雖然實作人員一定會有反對的理由，因為這樣會少賺很多薪水，但是這些理由，作者都一一地解釋並不成為問題，另外實作人員也不用怕沒事做，其實事情還是很多的，要怎麼做，就端賴領導者的能力吧。

最後作者做這樣的結論，『要達成概念整體性，真的是有賴於讓系統反映出單一的理念，使用者介面的規格必須出於少數人的構想。雖然將人力切分為架構設計、實作和實現三部份，但並不意味這麼做就會花掉更多的時間，由經驗可知剛好相反，整個系統的設計不但進行更快，而且花在測試的時間會比較少。效果是，垂直分工將大幅減輕水平分工所產生的負擔，其結果也將大幅簡化溝通，並且增進概念整體性。』

聽起來好像共產主義、資本主義、民主社會主義、社會民主主義，共產主義跟資本主義已經慢慢往民主社會主義或社會民主主義，但那一派會勝利，看來還是人民的依歸跟上天的指示有關係，並非吾等小民可以決定的，我可以繼續紀錄這樣的軟體歷史，讓後代可以請清楚。

Tags: architecture, cost-performance ratio, ease of use, implementation, ratio of function to conceptual complexity, ratio of gain to cost, simplicity, THE MYTHICAL MAN-MONTH, 使用便利性, 功能概念複雜度比, 實作, 成本效能比, 架構, 獲益成本比, 簡單性
Posted in THE MYTHICAL MAN-MONTH | No Comments »

The Introduction of “No Silver Bullet”Refired

2011-05-21,Last modified: 2011-05-20Please wait

這是人月神話：軟體專案管理之道（20週年紀念版）的第十七章：再論「沒有銀彈」(“No Silver Bullet”Refired)，上一篇沒有銀彈：軟體工程的本質性與附屬性工作（No Silver Bullet – Essence and Accident in Software Engineering），ㄚ琪說過很抽象又很長的文章，之後過了九年，作者自栩預言滿準的，看來比王老師準，但是卻也引發了很爭議，原因就是ㄚ琪說的，太抽象了，每個說詞都很難懂，所以作者針對這說爭議，再繼續說明，我們也就繼續地看好戲。

含糊不清的用語將造成誤解，這節裡頭的主題就是如此，我本身也有點懷疑作者自打嘴巴，因為真的很抽象，你就得花很多時間解釋，而使用者也得聰明很容易融入那個意境才能懂，所以作者被很多人批評沒有講得很清楚，首先的議題就是附屬性(accident)跟附屬的(accidental)的混淆，就英文看起來好像是意外，偶然發生的，但是作者說那是次要的，不過我們從中文翻譯來看應該不會混淆不清，除非譯者翻的有問題。

所以作者說在軟體開發裡頭，『本質性(essence)工作，所指的就是概念構造的創作智能』，『附屬性工作指的是實作的程序』，這樣的解釋希望大家能比較懂，但是ㄚ琪還是抱著懷疑的態度。

在對事實的一項質疑裡頭，甚至連赫茨伯格的雙因素理論也把激勵因素跟保健因素用來抨擊這篇文章，但是以我初淺的瞭解，這個研究好像比較針對勞工，相較於軟體開發來說，這個理論是否完全用得上就有疑問了，不過文章中把生產力拿來討論或許也不錯吧。

本質性工作很困難所以就無望了嗎？原來There Is a Silver Bullet裡做反擊了，『採取可再利用(reusable)、可替換組件的方式，來對付屬於概念本質性部份的問題，我由衷地表示贊同。』，作者先表示贊同，後面還是說到但是…，然後開始反駁，似乎這就是論文口試的一種常見到的劇情不是嗎？

就複雜性的層級來說，反正就一個字complex複雜，來述說我的感覺吧。

Harel的Biting the Silver Bullet（中譯咬緊銀彈），看來大家很喜歡一直針對銀彈做討論喔，不過ㄚ琪此刻讀來有點意興闌珊了，但是David Harel可算是有來頭的人物，可以從維基及他的網頁看出來，而這篇的文章在文中以悲觀、樂觀與事實來討論，作者直說很多程式設計師有樂觀的職業病，ㄚ琪看起來好像也是如此，難道樂觀不好嗎？應該沒什麼不好，但可別樂觀過了頭，所以我想這些事實ㄚ琪頗能接受的。

Harel覺得沒有銀彈的原因有三點：

本質性與附屬性的清晰劃分
獨立地評論每個銀彈
只預測了十年，這樣沒有足夠長的時間“出現任何重大的進步”

囧，本質性與附屬性這種太深奧的問題，看起來大師都很喜歡討論喔，我只覺得有點愛睏，但是看到大師還努力地做實驗，ㄚ琪應該覺得汗顏才對，不過這個實驗是基於歸繆法(reducto ad absurdum)，常聽過歸納法，很少聽過歸繆法，不過另一個名詞反證法應該就有聽過了，維基這樣寫：『

反證法（又稱歸謬法、背理法）是一種論證方式，他首先假設某命題不成立（即在原命題的條件下，結論不成立），然後推理出明顯矛盾的結果，從而下結論說原假設不成立，原命題得證。

反證法常稱作Reductio ad absurdum，是拉丁語中的「轉化到不可能」，源自希臘語中的「ἡ εις το αδυνατον παγωγη」，阿基米德經常使用它。』不過用這樣的方式做實驗，被作者駁回，駁來駁去的很是精彩啊。

Harel後來有提出「香草框架」(The Vanilla Framework)的模塑技術(modeling technique)，而這這就是銀彈，作者倒是沒有駁回，只是說無法衡量好壞，看起來是一句話帶過了，不過或許是個好方法，但是這個方法ㄚ琪也不甚是很瞭解，期待有機緣可以碰到。

Capers Jones是一個在軟體工程方法上的專家，他也有他的官點來反對沒有銀彈，他說：『非也，把重點放在品質上，生產力將隨之而來。』他認為，只要是成本過高和時程落後的專案，都耗費了非常多的額外時間和工作在尋找並修正規格、設計、實作中的錯誤。這裡頭講到品質，那麼，生產力的情形如何？被作者點到了，生產力值難以評估，這類的工作的人做得要死要活卻很容易被低估了，理由是沒有performance輸出給主管的看，如果這位主管習慣用監控線上生產的角度來看，我想程式設計師或是設計師之類的人會很難生存下去，Sophia看起來就面臨了這種情形，而我也想擺脫這樣情形，可是文章很少有人按讚，看來也很難跳多出來。

續談到套裝軟體-用買的；不要自己做以及威力強大的創作工具，好吧，不得不妥協了，我勸大家用，看來工作達人可能要改行寫軟體的分享了，寫程式少寫一點，創作工具也得好好分享，這樣的口味才能迎合大眾。

至於物件導向程式設計，這個已慢慢深耕於ㄚ琪的心中，只能被作者稱為是銅彈，而且被質疑為可行嗎？

這種看起來用大塊積木來建構的技術，其特徵是，模組化(modularity)和簡潔的介面。其次，它強調了封裝(encapsulation)，即外界無法看到元件的內部結構；它還強調了繼承(inheritance)和階層(hierarchical)結構的類別(class)以及虛擬函式(virtual function)。物件導向還強調了強制抽象資料型別(strong abstract data-typing)，它確保某種特定的資料型別只能由它適當的操作(operation)方法來操作。

一個『為什麼物件導向技術的成長如此緩慢？』，作者這樣敘述，不過ㄚ琪並不覺得成長緩慢，可能我並不是早期的那個時代的人吧，這個技術現在應該很火熱吧，不過作者提到的主要概念『投資集中在前期，回收集中在後期』，這樣看起來好像前人種樹，後人乘涼的感覺，既是如此，就真的是要看很長的一段時期了，Designing C++ Libraries有這樣一段『物件導向技術將不會使第一個專案的開發速度變快，下一個可能也不會，將要到同一類型的第五個專案才會明顯地變快』，想要搭快速列車的人，有沒人自願先做這列火車啊，ㄚ琪一定是繼續有耐心地等吧。

作者也提到了再利用的情形，從字裡行間來看，雖然有了物件導向這個偉大的技術，但是再利用性好像很低，不論是個人或團體層級來說都不是很高，但是如果從開放原始碼的觀念來看，我覺得再利用性，會慢慢提高，但是前提是要有人願意分享，而且這種人可以活下去，那麼再利用性要提高不是難題，這不就事看在神眼光是多麼美好的一件事啊。

作者接下來預測了一個可預測卻未預測的軟體再利用問題—學習大量字彙，我想這個預測現在應該已經實現了，看看Java的函式庫手冊吧，歷經了無數版別的開發，ㄚ琪覺得真的越來越厚了，難怪手冊一直翻不完，甚至覺得買那麼大本的手冊要當枕頭睡嗎？可是又很難睡啊。

最後的結論，雖然很多人要反駁，但是作者一一地駁回，並且說形勢沒有改變，至於真的是否沒有改變，ㄚ琪也無法評論，好像沒辦法繼續寫下去了，我想我還是繼續用分享心得的方式來寫下去，用學習的心態來看這本書，或許會比較快樂。

Tags: reducto ad absurdum, Silver Bullet, THE MYTHICAL MAN-MONTH, 本質性, 歸繆法, 赫茨伯格, 銀彈, 附屬性, 雙因素理論, 香草框架
Posted in THE MYTHICAL MAN-MONTH | No Comments »

The Introduction of No Silver Bullet – Essence and Accident in Software Engineering

2011-05-14,Last modified: 2011-05-11Please wait

這是人月神話：軟體專案管理之道（20週年紀念版）的第十六章：沒有銀彈：軟體工程的本質性與附屬性工作（No Silver Bullet – Essence and Accident in Software Engineering），這一篇文章落落長而且一開始在摘要就有一個註解，ㄚ琪好奇地去看，赫然發現原來這一篇不是原作者的文章，這是出於Information Processing 1986, 由H. –J. Kugler (1986)所編輯的the Proceedings of the IFIP Tenth World Computing Conference, pp. 1069-76. 在IFIP和Elsevier Science B. V., Amsterdam, The Netherlands授權轉載的，難怪看起來很像是論文的文章，讀來也不是很順，不過還是得分享自己的讀後心得看看。

篇名中的本質性指的是『去創造出一種由抽象的軟體實體所組成的複雜概念架構』，附屬性則指『用程式語言來表現這些抽象的實體，並在某些空間和速度的限制之下，將程式對應至機器語言』。當我們在努力克服附屬性的工作時，作者認為我們再怎麼努力也無法讓開發工作有一個數量級的提昇，所以接下來的就只能從本質性工作來著手了。

這裡有幾個建議，引用簡體版的：

仔細地進行市場調查，避免開發已上市的產品。
在獲取和制訂軟體需求時，將快速原型開發(rapid prototyping)作為迭代計畫的一部分。
有機地更新軟體，隨著系統的運行、使用和測試，逐漸添加越來越多的功能。
不斷挑選和培養傑出的概念設計人員。

避免開發已上市的東西確實是一個捷徑，但ㄚ琪會悲觀地看是軟體工程師的無用之時，因為別人有了，我們就用買的就好了，延伸到現在很多的軟體一直外包到大陸到印度，就是這樣的情形，這是從成本面上來考量，如果就安全面上來考量，或許就不是這麼一回事了。另外可能也是另一個新興工作的開始，這裡就題到了概念設計人員這個名詞，概念設計這個名詞可以發現很多是指創意方面的設計人員，所以像是建築、工業設計之類的工作，概念設計人員確實有其需要和供給的空間，但是在軟體界來說至少就台灣來看，好像沒有這一號的人物，或許我太孤陋寡聞吧。

在簡介這裡提到我們對疾病的看法，已經從惡魔說(demon theory)進步到體液說(humours theory)，再進步到細菌說(germ theory)，作者也很有信心，軟體工程也會這樣的，只是那時的軟體工程到底是在舊石器時代，還是新石器時代呢？現代的軟體工程又處在那個時代呢？ㄚ琪就不得而知了。

在註定就是要那麼辛苦嗎？–本質上的困難這裡，軟體開發的真正困難是『在於這種概念構造的規格制定、設計和測試，而並非在孜孜矻矻於它的呈現方式，以及測試該呈現方式的精確程度。』本質這兩個字感覺就很抽象，作者繼續用複雜度(complexity)、配合性(conformity)、易變性(changeability)、隱匿性(invisibility)做討論。

複雜度在這裡我只要說軟體實體的規模是舉世無雙的，這裡頭因為如此造成技術上的困難、管理上的問題，以及阻礙概念整體性(conceptual integrity)，並且難以發現疏忽的錯誤以及學習及理解上的困難，看到這頭應該開始暈了吧。

配合性的主軸就是軟體得配合人類現有的制度和系統的介面，這點倒說得較容易懂。

易變性來說，軟體碰到比房屋建築、電腦硬體及汽車更大的壓力，你看動不動就叫你改程式，你會常聽人說你給我改房子或改車子嗎？很少，而且工程號大成本也高，但是程式的變動總讓人覺得容易太多了，所以就會一直改改改。

軟體是很抽象的東西，它不像房子那樣可見，正因為這樣所以它的隱匿性就很高，高到可能你做了什麼努力，老闆看不出來。

在過去的突破所解覺得都是附屬性的難題，看來作者很直言不諱喔，像高階語言的使用，看起來是被認定微附屬性的工作。而分時技術的解決緩慢的回覆時間，也被認定是軟體開發過程中的附屬性難題的解決，所以還不是本質性。統一的軟體開發環境，我想我同意，所以就不用多說了。

尋找銀彈，在前面那節中，作者否定了高階語言、分時技術跟統一的軟體開發環境是本質性的工作解決，再這節裡要繼續探討幾個技術是否算是本質性的，ㄚ琪也一一地來看這些技術的意義並分享出來。

Ada和其他高階語言的進展，『Ada，是一種程式語言。源於美國軍方的一個計劃，旨在整合美軍系統中運行著上百種不同的程式語言編寫的程序，命名是為了紀念愛達·勒芙蕾絲而使用Ada。…Ada語言的重要特徵就是其嵌入式風格，模塊化設計，編譯檢查，平行處理，異常處理及泛型編程。Ada在95年加入了對物件導向設計的支持，包括動態分配等。…它被廣泛應用於一些非常重要的系統中，例如航空電子學，武器及太空飛行器的作業系統中。』這些ㄚ琪都摸不著邊，所以我無緣瞭解Ada，但是看來Ada不是本質性的工作解決。

物件導向程式設計，這是大家現在再熟不過的計術了，很可惜它也不是。

『人工智慧（英語：Artificial Intelligence, AI）有時也稱作機器智能，是指由人工製造出來的系統所表現出來的智能。通常人工智慧是指通過普通計算機實現的智能。該詞同時也指研究這樣的智能系統是否能夠實現，以及如何實現的科學領域。』，文中AI有分AI-1及AI-2，而AI-1則是這裡所指的人工智慧，不過這門技術頗深，ㄚ琪也摸過一點邊而已，但它也不是。

『專家系統是早期人工智慧的一個重要分支，它可以看作是一類具有專門知識和經驗的計算機智能程序系統，一般採用人工智慧中的知識表示和知識推理技術來模擬通常由領域專家才能解決的複雜問題。』所以這裡指的是前面說的AI-2，不過它也不是。

「自動化」程式設計(Automatic programming)，它可不是在說CIM喔，我的認知是程式自動設計程式，其實我的認知並沒什麼問題，但是文中這段『簡而言之，自動化程式設計從來都是一種好聽的說法，骨子里其實是用更高階的語言來編寫程式，比程式設計師目前所使用的語言還要高階罷了。』讀到這裡有點失望，不過也算認這個解釋，因此它也不是。

圖形化程式設計，這個真的也不用多說，太多視窗了，夠視覺吧，不過它也不是。

軟體的驗證，當然也不是。

環境與工具，『軟體開發環境上，現在已經實現的最大成果可能是整合資料庫的使用，用來追蹤大量的開發細節，供每個程式設計師精確地查閱資訊，以及在整個團隊協作開發中保持最新的狀態。』這也不是本質上的改進，唉。

工作站，別想了，它當然不可能是。

分享這麼多的技術，但是多不是，那麼在概念上大有可為的做法是什麼？外購與自製，『軟體開發最極端的可行方案，就是根本不要自己開發』，這還真廢話喔，但是真理，不過從事軟體開發的人可能就要失業了，改賣雞排嗎？所以像微軟的辦公室軟體，你只要會了，我想很多程式就不用再設計了，的確，這太具威力了，但是還是有這類軟體不能做的事，不過我想也撐不了多久，我倒希望這日子不要太早來臨，不然很快就要找另一份工作了。

需求的提煉與快速原型製作，這裡頭提到客戶的需求要再提煉萃取，這裡頭其實是頗高難度的挑戰，ㄚ琪到現在還沒碰到這樣厲害的客戶，都是要再訓練，不過這個成本應該很可觀，但是確實是本質性工作的解決。

漸進式開發-發育軟體，而非建構軟體，作者說『我現在還記得在1958年，當聽到一個朋友提及建構（building），而不是寫（writing）程式時，我所感受到的震驚。』今天ㄚ琪也要說，原來寫成式跟建構程式有這麼大的差別，ㄚ琪在跟人自我介紹時都會用到寫程式這個字眼，大家也都懂，但是今天才知道用建構程式看起來比較貼切我的工作，而建構這個字眼ㄚ琪其實很早就看見過，只是沒想到有這麼大的差異，好吧，下次要改用建構程式來自我介紹了，但是現在或許又要改成發育程式了，理由是程式要慢慢地漸進開發，這還真是酷的說法啊，但是我這樣自我介紹你會懂嗎？我自己都不太懂，也很難向人解釋。

偉大的設計師，繼續用我以前主管口頭語，『找對的人做對的事』，不管你在工作上或事工上，都要面臨這樣的抉擇，不管怎樣，制度還是沒法優先於人，所以是否能培養偉大的設計師，是否有方法，應該有人會感興趣，但是實際上，似乎不會有組織會花那麼多的心血在尋找和栽培偉大的設計師吧，嗯，成本應該不低，所以作者給出了個建議『每個軟體機構必須下定決心表明，傑出的設計人員和卓越的管理人員一樣重要，他們應該得到相同的培訓和報酬。不僅僅是薪資，還包括各個方面的認可——辦公室規模、安排、個人的設備、差旅費用、人員支持等——必須完全一致。』有這個宣言真酷，這樣ㄚ琪自然會努力學程式開發。

這裡也有養成偉大設計師的建議，『

盡可能早地、有系統地辨識出頂級的設計人才。最好的往往不是那些最資深的人員。
為設計人員指派一位職業導師，負責他們技術方面的成長，仔細地為他們規劃職業生涯。
為每個明日之星方面制訂和維護一份生涯成長計畫，包括與設計大師的、經過仔細挑選的學習過程、正式的高級教育和以及短期的課程——所有這些都穿插在設計和技術領導能力的培養安排中。
為成長中的設計人員提供相互交流和學習的機會。』
希望有這樣的伯樂，但是我想這不是作者要在這裡做討論，所以要看看以後有無章節討論。

Tags: Silver Bullet, THE MYTHICAL MAN-MONTH, 本質性, 銀彈, 附屬性
Posted in THE MYTHICAL MAN-MONTH | No Comments »

The Introduction of The other face

2011-05-06,Last modified: 2011-05-04Please wait

這是人月神話：軟體專案管理之道（20週年紀念版）的第十五章：一體兩面(The other face)，簡體版譯作另外一面，到是很直覺，而一體兩面四個字用起來很像是成語，不過譯的是否貼切，有待進一步觀察。ㄚ琪從頭到尾看完一遍，很抱歉看不出內容跟主題關聯的情形，倒是開場白歌德『What we do not understand we do not possess.』『我們無法主宰我們不瞭解的東西』，倒是滿貼切的，這一篇對ㄚ琪來說，是個很實用的建議，我應該會把裡面的教學做在我的程式裡頭。本篇的重點就是「如何」寫好文件。

該寫哪些文件？

為使用程式而寫的文件 這裡主要針對文件應該先有概觀性的描述(overview)，作法引用簡體版並譯成繁體字使用如下：

1. 目的。主要的功能是什麼？開發程式的原因是什麼？

2. 環境。程式運行在什麼樣的機器、硬體配置和作業系統上？

3. 範圍。輸入的有效範圍是什麼？允許顯示的合法範圍是什麼？

4. 實現功能和使用的演算法。精確地闡述它做了什麼。

5. 輸入－輸出格式。必須是確切和完整的。

6. 操作指令。包括控制臺及輸出內容中正常和異常結束的行為。

7. 選項。用戶的功能選項有哪些？如何在選項之間進行挑選？

8. 運行時間。在指定的配置下，解決特定規模問題所需要的時間？

9. 精度和校驗。期望結果的精確程度？如何進行精度的檢測？

這樣就可以寫出3到4頁的摘要性說明，這裡頭有些ㄚ琪還需要改善自己的文件說明，但是環境常常會省略掉，以後應該會加入進來。

為建立對程式的信心而寫的文件 這句話的意思就是增加測試案例(test case)，我倒是沒有寫這個文件的習慣，改吧。這種文件有三部份：主案例、罕見合法案例及罕見不合法案例。

為修改程式而寫的文件 包含的部份：

1. 流程圖或副程式的結構圖，對此以下有更詳細的論述。

2. 對所用演算法的完整描述，或者是對文件中類似描述的引用。

3. 對所用檔案規劃的解釋。

4. 解譯階段結構(pass structure)的概觀——從磁片或者磁帶中，獲取資料或程式處理的序列——以及在每個處理過程必須完成的操作。

5. 初始設計中，對已預見修改的討論；特性、可插入點(hooks)與離開點(exits)；原作者對可能會擴充的地方以及可能處理方案的一些意見。另外，對隱藏缺陷的觀察也同樣很有價值。

惱人的流程圖

這個流程圖到是很讓ㄚ琪頭痛，因為ㄚ琪從來沒有將流程圖做出來過，但是在看別人寫的程式時，卻又很希望作者有流程圖可以讓人參考，很矛盾吧，好在作者也不建議做流程圖，終於有跟ㄚ琪同一陣線的人了，給個讚，但是作者反倒建議將程式轉成以執行階段或步驟為主的結構圖，然後畫在一頁大小的流程圖上，倒是滿方便的，舉例如下圖：