# 三十五、提防非自主開發綜合癥
猜謎時間到了。
1.程序代碼重用是:
a)好的
b)不好的
2.重新發明輪子是:
a)好的
b)不好的
3.非我發明(Not-Invented-Here)癥是:
a)好的
b)不好的
當然啰,每個人都知道應該要善用別人的工作成果。所以正確答案當然就是1(a) 2(b) 3(b)。 確定嗎?
別說得那么快!
非我發明(NIH)被公認為典型的管理病狀,指某個團隊拒絕使用不是自己創造的 技術。NIH癥的患者顯然只是很小家子氣,只因為沒辦法居功就拒絕為整體組織 的利益貢獻(對吧?)。你可以在當地大書店的沈悶商業史區找到一堆故事,說愚 蠢的團隊花了幾百萬美元和12年的時間,卻只做出某些只要9.99元就能在 Egghead(譯注:在線零售商)買到的東西。任何人只要有注意過去三十年間計算 機程序設計的進展,就會知道重用是所有現代計算機系統的圣杯。
沒錯,我也是這樣想的。所以我在做第一版Visual Basic for Applications的 項目經理時,就很小心的聯合了四個(注意是四個哦)微軟內不同的團隊,要做出 Excel VBA里的定制對話盒。整個想法非常復雜而且各部門間相互牽連。有個叫 AFX的團體在制作某種對話盒編輯器。然后我們會利用OLE團體新寫的程序把一個 應用程序嵌入在另一個程序里。而Visual Basic團隊則是提供里面的程序語言。 經過幾星期的協商,AFX和OLE還有VB團隊原則上都同意這個作法。
我去到Andrew Kwatinetz的辦公室。他當時是我的經理而且我知道的一切都是他 教的。「Excel開發團隊絕對不會接受這個方法,」他說:「你知道他們的格言 嗎?『找出相關性,然后去掉。』他們絕對不會接受這么不獨立的東西。」
真-有-趣-啊。這事我竟然不知道。我想這解釋了Excel團隊有自己的C編譯程序的 原因了。
現在我確定很多讀者已經笑到在地上打滾。「微軟真是笨啊,」你會這樣想「他 們拒絕用別人的程序代碼,而且只是為了一個產品還自己做編譯程序。」
別說得這么快,老弟! Excel團體粗魯的獨立心態意味著他們總是能如期上市, 而且出來的程序代碼都有一致的高水平。另外他們的編譯程序(由80年代開始的) 會產生pcode,所以不必修改就能在Intel計算機和麥金塔68000芯片的系統上執 行。pcode也使得執行檔在Intel平臺上只有原本的一半大小,所以由軟磁加載時 能更快啟動而且需要較少的內存。
「找出相關性,然后去掉。」當你在一個非常非常優秀,有著偉大程序員的團隊 工作時,其他人的程序坦白說都是有蟲的垃圾,何況其他人都沒法子準時上市。 如果你是法國藍帶學院的主廚,需要新鮮熏衣草時你會自己種而不是去菜市場買, 因為有時候新鮮的熏衣草可能會缺貨,有時候店家可能拿不新鮮的熏衣草假裝新 鮮賣給你。
事實上最近的網絡熱潮中,一堆裝內行的企業作家說未來的公司會完全虛擬化, 公司變成只有幾個時髦的家伙待在起居室里喝著白葡萄酒,所有事情都外包出去 做。這些換氣過度的「夢想家」并沒有注意到市場機制是為所增加的價值而付錢 的。一個客廳加上兩個雅痞,向A公司買一套電子商務引擎,拿B公司做的貨來賣, 再找C公司處理庫存和送貨,客戶服務則交給D公司,這種作法實在沒有增加什么 價值。事實上如果你曾經把很關鍵的業務拿去外包,就會了解外包其實是個地獄。 不能直接控制客戶服務,客服就會爛到不象話,爛到像某人在網志上寫的,想在 電話公司找個人(任何人都好)去做些最最簡單的事都辦不到。如果物流外包出去,你的物流包商或許對實時送達會有不同的認知,而你的客戶就會不太高興,可是 你一點辦法都沒有,因為重新找一個物流包商要花三個月。何況事實上你根本不 會知道客戶不高興,因為他們找不到你,因為你設立了一個外包的客戶服務中心, 宗旨就是不要讓自己聽到客戶的聲音。至于你買的電子商務引擎?絕對不可能像 Amazon用obidos做的那么有彈性,obidos可是人家自己寫的(否則Amazon跟買那 種東西的競爭者相比就沒有優勢了)。另外也沒有現成的web服務器在速度上比得 過Google自己親手制作并優化的服務器。
很不幸的這個原則似乎與「重用程序代碼好,重新發明輪子壞」的想法直接沖突。 我能給的最好建議是:
如果是核心的事業功能,不管是什么都要自己來做。
找出你的核心事業能力和目標,然后在公司內執行。如果是家軟件公司,寫出優 越的程序代碼就是成功的方法。公司餐廳和光盤壓制都可以外包出去。如果是家 藥廠,就去寫藥物研究的軟件,可是不要寫自己的會計軟件。如果是家網絡會計 服務公司就寫自己的會計軟件,不過別想做雜志廣告。如果有客戶的話就千萬不 要把客戶服務外包出去。
如果你在開發計算機游戲,而且地圖(plot)部份是你的競爭優勢,大可去用其他 廠商提供的3D鏈接庫。不過如果游戲特色是很酷的3D特效,3D程序部份最好自己 來。
我懷疑這個規則唯一的例外,就是當你自己的人完全比不上別人,不管自己 做什么都會失敗。沒錯,這種地方很多。如果是這種情況,我就幫不上忙了。
- 第一部分 位與字節:編程實踐點滴
- 一、語言的選擇
- 二、深入底層
- 三、joel測試:改進代碼的12個步驟
- 四、每一位軟件開發人員必須、絕對要至少具備UNICODE 與字符集知識(沒有任何例外!)
- 五、輕松寫就功能規格說明書 - 第1節:為什么煩心?
- 六、輕松寫就功能規格說明書 - 第2節:什么是規格說明書?
- 七、輕松寫就功能規格說明書 - 第3節:但是……如何?
- 八、輕松寫就功能規格說明書 - 第4節:技巧
- 九、輕松制訂軟件進度表
- 十、每日連編是朋友
- 十一、難伺候的故障修復
- 十二、軟件開發中的5個世界
- 十三、稿紙原型開發
- 十四、不要被太空架構師所嚇倒
- 十五、開火與運動
- 十六、人員技能
- 十七、源于計算機學科的三個錯誤思想
- 十八、二元文化
- 十九、自動獲取用戶故障報表
- 第二部分 開發人員的管理
- 二十、面試游擊指南
- 二十一、重金激勵害多利少
- 二十、二不配備測試人員的五個首要(錯誤)原因
- 二十三、任務換人有害無益
- 二十四、絕不去做的事情,第一部
- 二十五、冰川下的秘密
- 二十六、漏洞抽象定律
- 二十七、程序設計界的LordPalmerston
- 二十八、評測
- 第三部分 Joel對常態問題的遐想
- 二十九、RickChapman解讀愚昧
- 三十、在這個國家狗是干什么的? 我們有多么天真?
- 三十一、作為哼哈二將,只管去做事
- 三十二、兩個故事
- 三十三、巨無霸麥當勞與天才廚師JamieOliver
- 三十四、沒有什么像IT看起來那么簡單
- 三十五、提防非自主開發綜合癥
- 三十六、策略I:BEN&JERRY公司與AMAZON
- 三十七、策略II:雞與蛋問題
- 三十八、策略III:讓我回去!
- 三十九、策略IV:大件與80/20神話
- 四十、策略V:公開源代碼的經濟因素
- 四十一、墨菲法則肆掠的禮拜
- 四十二、微軟公司是如何敗北API之戰的
- 第四部分 對.NET稍多的評說
- 四十三、微軟精神失常了
- 四十四、我們的.NET對策
- 四十五、請問,我可以使用連接程序嗎