Bug 與 皇上

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

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

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

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


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

留言

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

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

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

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

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

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

    回覆刪除
  4. 這讓我想到剛剛看過的一篇文章:

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

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

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

課程改進