# 三十五、提防非自主开发综合症
猜谜时间到了。
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对策
- 四十五、请问,我可以使用连接程序吗