Bug 與 皇上

作者：
一夥程式設計師正在啟奏當今皇上。『今年有什麼偉大的成就嗎？』皇上問道。

程式設計師私下討論了一會兒，然後回話：『比起去年，我們今年多修正了50% 的Bug』

皇上滿臉困惑的看著他們。他們顯然並不知道『Bug』是什麼。他低聲與宰相商量一會兒，然後轉向這些程式設計師，面露慍色。『你們犯了品質管制不良之罪。明年起不得在有任何的Bug！』他當庭宣下這道聖旨。

當然啦，明年當這夥程式設計師再度向皇上奏報時，就完全不提 Bug 的事了。

以上是取自 G.M. Weinberg 的著作 Quality Software Management v1: System thinking 的中譯本：軟體管理學-系統化思考 內的一個小故事。Prof. Wenberg 是我個人滿喜歡的一位軟體工程作家，他總是能用淺顯易懂的小故事道破許多軟體工程的問題。把這本好書推薦給大家，有空的話真的可以好好看看。
生活樂趣

留言

  1. 黃為德2008年12月29日 下午5:58

    Gerald M. Weinber教授的這一則"paradox"，在我看來類似「國王的新衣」的另一版本，而且有違實際，並不怎麼高明，就如一個人有病，故意隱瞞並不等於沒病，而且可能會使病情惡化，類此，隱藏軟體的bug，不讓皇上知道，bug仍然存在，也許程式設計師可能已偷偷de-bug，只不過讓皇上窮高興而已，這樣做似有拍馬屁之嫌，無濟於提升軟體品質，任何人寫的程式不可能沒有bug，我認為廣義的bug不只是程式的錯誤，軟體產品不符需求也算是另一種型態的bug，要避免bug的產生(當然不能完全)，提高軟體發展方法的「抽象層次」(level of abstraction)是方法論專家努力的方向與成果，例如Agile Method或MDA，講白一點，要減少bug的產生，最好從methodologies着手，不知方家們同意否？

    (註)做為設置這個部落格的原始提案人，時常扮演烏鴉或事後諸葛亮的角色，無他，只不過希望部落格的內容能引起大家的討論，甚至於「激烈」討論，現今看來雖已漸入佳境，但尚須加油。

    回覆刪除
  2. 薛念林2008年12月29日 晚上9:19

    我也來說說我喜歡這個小故事的原因。文中寫的『皇上滿臉困惑的看著他們。他顯然並不知道Bug是什麼』，這裡暗喻著了解bug並不容易，管理者通常不了解，只是一味著要求『沒有bug』，卻不知道更重要的是去面對它、處理它、駕馭它，讓它處在一種可以被控制的狀態。

    當皇上用鴕鳥心態去看待Bug時，Bug並不會消失。程式設計師只會『隱惡不報』，到某一天不可收拾時，系統只好宣告失敗。

    正確的作法應該有一套錯誤的追朔系統系統去記錄所有的錯誤，按部就班的處理這些錯誤。有點類似民主制度的『監察院』？Anyway, 我覺得用皇上這種譬喻來凸顯一個荒謬的錯誤決策是蠻有趣的。

    回覆刪除
  3. 黃為德2008年12月31日 晚上10:17

    任何雋語都可能依個人的角度與看法，有不同的詮釋與感受，而無所謂對錯。我評論Prof. Weinberg這則故事是從"separation of concerns architecture"的角度加以評述，如果這位皇上扮演的角色是董事長，這則雋語是可圈可點，但如果他要扮演專案經理(也許他不願意)，這位皇上就自以為穿了新衣，其實並沒穿衣，因為他雖然不懂何謂bug，但卻可評論品質不良。我記得前一陣子軟工部落格有一則諺語，說「‧‧‧變化趕不上老闆的一句話」，我當時的意見勸老闆不要亂開腔，要開腔先讀一讀F. Brooks的"The Mythical Man-Month"，Prof. Weinberg的這則故事是出自他1991年著的"Quality Software Management: Systems Thinking, vol. 1"(我不知有沒有近代版本)，以當時軟體工程技術而言，這則故事十分精彩，但以目前的軟工技術而言，這則故事只反應軟體發展的一小部分。

    回覆刪除
  4. 日落 Zero2010年3月30日 凌晨12:55

    這讓我想到剛剛看過的一篇文章：

    完美軟體經濟學
    http://it.solidot.org/it/10/03/29/1153230.shtml

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

作者：
CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法
閱讀完整內容

CRC cards - 非正規物件導向發展技術

作者：
圖片
最近看到Kent Beck與Martin Fowler講的一句『諺語』，說："Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文，提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』，溝通在軟體發展的過程中十分重要，尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto)，此地不宜對宣言多做闡述)，問題是你要使用何種工具或方法來溝通？我想除use cases外，CRC cards可能是最佳工具之一，它是隨時隨地可得的低技術工具，易學易用。 軟體開發與維護時，工作夥伴的合作十分重要，換言之，團隊合作是發展工作成敗的關鍵，夥伴合作必須有好的工具或技術協助，CRC cards可能是適當的工具之一，據我所知，在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997)，而這種技術雖然簡單，但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別，因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術，而且也希望各界人士能予指正。 CR C cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html)， 其出現時期與WWW相同，至今約有20幾年的歷史，這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作，後來的演變卻超乎在教室內的需要，而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach)，雖然屬非正規方法，但CRC cards可做為正規方法的輸入或前端作業，如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOS
閱讀完整內容

課程改進

作者：
今年在輔大招開的TSCE11，其中在Panel Discusion中(主題：軟體核心能力)，我提議軟工教育訓練由OO modeling概念開始，而程式則依據models來撰寫，這種提議可能須修改教學程序，不過我認為，「軟體核心能力」的目的乃是要建立優良的軟體系統，而models比複雜的程式容易描述系統，也比較容易保養系統，因為其抽象層次較高，也符合程式語言以及軟體發展方法的演變之故。我提出這種意見，希望對軟體工程教育有興趣的人士能夠討論，提供意見。
閱讀完整內容