白癡驅動開發方法

軟件產業是世界上最盛產新管理製度的產地。從敏捷開發方法到極限編程到測試驅動開發方法(TDD)，諸如這樣的縮寫名稱和框架還在不斷湧現。為什麼會這樣？

有人說是這個產業還不成熟：軟件工業還很年輕，每一次的創新都是向真正真理靠近一步。另外一些人說是因為軟件人喜歡整事兒，神經質不能自控。而我要說的是，如果在這個過程中我們獲得了不少可以稱之為楷模的成果，那麼，同樣，誠實的說，我們也造就了不少具有諷刺意味的理論方法，並在很多時候實實在在的被人使用。

(我相信下麵這個列表是很搞笑的，同時也很具有諷刺意味)。

任何一個開發團隊，當他們的所有重大決定都由那個最大的偏執狂決定時，這就形成了白癡驅動開發模式。隻要白癡先生在屋內，所有的智慧，邏輯和處理方法就都會被排擠到窗外，不管是多麼的愚蠢、自私的事情，但隻要是他想出來的，那就是最好的。雖然有製度和步驟方法，但白癡先生並不理睬，沒人去遵守。

在一個組織裏，有兩夥或更多的人，他們對軟件應該如何被開發出來的信念有分歧。這些信念分歧造成的緊張局勢——體現在每次會議中的鬥爭，雙方陣營中關於個人觀點的爭辯——最終更大的影響了項目的決定，而對軟件的真正信仰卻被拋在了腦後。

所有個人努力的動力都來自確保當災難發生時自己不受責備。

每個人都在假裝知道有辦法能解決目前正在發生的事情，而且事情能一切順利，但現實情況是，事情一團糟，沒有任何措施動作來應對這些問題。而當事情進一步變遭時，會有更多的人變成通過否認事情的真相或把自己隔絕到自己負責的項目中的那一小模塊裏來聊以自慰。

人們寫代碼、做設計的唯一目的就是增加他們的曝光度、滿足老板們的怪念頭、加速他們仕途晉升的速度或坐到最豪華的辦公室裏——不管他們的工作努力方向離既定的目標相距多遠。這包括致使災難發生來讓某人成為英雄，寫出短期來看是非常精彩的修改但當人員變更後會導致災難後果的代碼，注重表麵工作而忽略實際價值。

我相信你一定還看到過其它種未提到的工作方法論——說說吧，讓大家開開眼界。

最後更新：2017-04-02 15:15:16