Joel on Software
In Defense of Not-Invented-Here Syndrome
by Joel Spolsky Sunday, October 14, 2001
Time for a pop quiz.
让我们来做个流行的测试。
- Code Reuse is:
a) Good b) Bad
一．代码复用是：
a)好的 b)坏的。
- Reinventing the Wheel is:
a) Good b) Bad
二．重新发明轮子是:
a)好的 b)坏的。
- The Not-Invented-Here Syndrome is:
a) Good b) Bad
三．非我所创综合征是:
a)好的 b)坏的。
Of course, everybody knows that you should always leverage other people's work. The correct answers are, of course, 1(a) 2(b) 3(b).
当然所有人都知道应该要借助于其他人的工作。因此正确答案当然是。a) b) b)
Right?
对吗？
Not so fast, there!
嘿,没这么快。
The Not-Invented-Here Syndrome is considered a classic management pathology, in which a team refuses to use a technology that they didn't create themselves. People with NIH syndrome are obviously just being petty, refusing to do what's in the best interest of the overall organization because they can't find a way to take credit. (Right?) The Boring Business History Section at your local megabookstore is rife with stories about stupid teams that spend millions of dollars and twelve years building something they could have bought at Egghead for $9.99. And everybody who has paid any attention whatsoever to three decades of progress in computer programming knows that Reuse is the Holy Grail of all modern programming systems.
非我所创综合症通常被视作一种典型的管理层通病。情况下一个团队会拒绝使用非她们自己所创的技术。患有非我所创综合症的人通常是小气的，他会拒绝做出对整个组织最有利的决定。因为他们发现自己没办法从中受益。不是吗？本地的大型书店的无聊商业史分区都会充斥着各种故事，关于那些愚蠢的团队花费了上百万美元数十年来搭建他们可以在Egghead上面用9.99刀就能购买到的产品。任何稍稍注意到近30年来计算机编程发展的人，都知道：复用是现代编程系统的圣杯。
Right. Well, that's what I thought, too. So when I was the program manager in charge of the first implementation of Visual Basic for Applications, I put together a careful coalition of four, count them, four different teams at Microsoft to get custom dialog boxes in Excel VBA. The idea was complicated and fraught with interdependencies. There was a team called AFX that was working on some kind of dialog editor. Then we would use this brand new code from the OLE group which let you embed one app inside another. And the Visual Basic team would provide the programming language behind it. After a week of negotiation I got the AFX, OLE, and VB teams to agree to this in principle.
是的，额，这也是我原来的想法。因此当年我担任负责VisualBasic应用程序开发程序经理的时候，我仔细地挑选了四个联盟团队，数一下，通过这四个微软的不同团队来获取ExcelVBA的定制对话框。这个主意很复杂，而且最后发现充斥着错误。一个叫做AFX团队负责设计某种对话框编辑器，然后我们会使用OLE团队提供的代码把一个应用程序嵌入到另外一个里面，然后VB团队会提供支持编程语言。经过一个礼拜的协商之后，我和AFX，OLE以及VB团队大致同意了这些原则。
I stopped by Andrew Kwatinetz's office. He was my manager at the time and taught me everything I know. "The Excel development team will never accept it," he said. "You know their motto? 'Find the dependencies -- and eliminate them.' They'll never go for something with so many dependencies."
我去拜访了Andrew Kwatinetz，他当时是我的经理，并且教会了所有我知道的东西。“Excel开发团队永远不会同意的”，他说到：“你知道他们你知道他们的格言吗？找出依赖，然后消除他们。它们永远不会采用如此多依赖的方案。”
In-ter-est-ing. I hadn't known that. I guess that explained why Excel had its own C compiler.
有点儿意思，我并不知道，我猜这也说明了为什么Excel团队有他们自己的C编译器。
By now I'm sure many of my readers are rolling on the floor laughing. "Isn't Microsoft stupid," you're thinking, "they refused to use other people's code and they even had their own compiler just for one product."
我想到现在有很多我的读者已经躺在地上笑得打滚了。微软实在太蠢了，你可能会想，他们拒绝使用其他人的代码，他们甚至为他们跟自己一个产品构建自己的编译器。
Not so fast, big boy! The Excel team's ruggedly independent mentality also meant that they always shipped on time, their code was of uniformly high quality, and they had a compiler which, back in the 1980s, generated pcode and could therefore run unmodified on Macintosh's 68000 chip as well as Intel PCs. The pcode also made the executable file about half the size that Intel binaries would have been, which loaded faster from floppy disks and required less RAM.
别这么快得出结论，大朋友。Excel团队固执执着的独立思维方式同样意味着他们每次都会准时发布，他们的代码一直都保持很高的质量。并且他们的编译器，哪怕追溯到二十世纪八十年代都能够产生出优化级别的P代码可以不用修改同时运行在Mactonish68000芯片以及英特尔电脑芯片上面。使得执行文件大小大概只有英特尔执行文件的一半左右。这样从软盘加载起来就可以更快，而且消耗更少的内存。
"Find the dependencies -- and eliminate them." When you're working on a really, really good team with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else knows how to ship on time. When you're a cordon bleu chef and you need fresh lavender, you grow it yourself instead of buying it in the farmers' market, because sometimes they don't have fresh lavender or they have old lavender which they pass off as fresh.
“找到那些依赖必须消除它们”。当你和和一堆伟大的程序员的时候工作在一个非常非常棒的团队的时候，老实讲，其他人写出的代码都是错误百出的垃圾。而且其他人并不知道如何准时发布。当你是一个蓝带大厨，需要新鲜的薰衣草的时候。你会自己种植而不是农贸市场上去购买。因为有的时候并不能从农贸市场上买到新鲜的薰衣草，或者要不就是他们的薰衣草已经过了新鲜期了。
Indeed during the recent dotcom mania a bunch of quack business writers suggested that the company of the future would be totally virtual -- just a trendy couple sipping Chardonnay in their living room outsourcing everything. What these hyperventilating "visionaries" overlooked is that the market pays for value added. Two yuppies in a living room buying an e-commerce engine from company A and selling merchandise made by company B and warehoused and shipped by company C, with customer service from company D, isn't honestly adding much value. In fact, if you've ever had to outsource a critical business function, you realize that outsourcing is hell. Without direct control over customer service, you're going to get nightmarishly bad customer service -- the kind people write about in their weblogs when they tried to get someone, anyone, from some phone company to do even the most basic thing. If you outsource fulfillment, and your fulfillment partner has a different idea about what constitutes prompt delivery, your customers are not going to be happy, and there's nothing you can do about it, because it took 3 months to find a fulfillment partner in the first place, and in fact, you won't even knowthat your customers are unhappy, because they can't talk to you, because you've set up an outsourced customer service center with the explicit aim of not listening to your own customers. That e-commerce engine you bought? There's no way it's going to be as flexible as what Amazon does with obidos, which they wrote themselves. (And if it is, then Amazon has no advantage over their competitors who bought the same thing). And no off-the-shelf web server is going to be as blazingly fast as what Google does with their hand-coded, hand-optimized server.
实际上在最近的.COM狂热中，一些庸俗的商业作者语言说：未来的公司肯定是完全虚拟化的。到时候公司不过是一对时尚的喝着名酒的夫妇在他们的起居室搞出来的，所有其他东西都会外包。这些一天一个变的幻想家们忽视的一点是：“市场只会为增值服务付费”。两个在起居室里面的自由职业工工作者，从A公司买来电子商务引擎，然后销售B公司的商品，发货由C公司负责，客户服务外包给D公司负责。想想，这样给客户带来了多大的增值服务呢？实际上，如果你把最核心的商业功能外包，你就会意识到外包简直就是噩梦。如果不直接控制客户服务，你得到的就是噩梦般糟糕的客户服务。就是那种人们在他们自己的网络日志里面提到的，当他们想从电话公司获得某个人任何人帮助来做一些最基本的事情却根本不可能。如果你外包你的发货过程，而你的合作伙伴对于完整的发货服务应该由哪些部分组成有着不同的观点，那么你的客户肯定不会对你的服务感到满意的。他们没法跟你沟通，因为你设立了一个外包的客户服务中心，你这样做的目的只不过是为了不想要聆听你客户的意见罢了。你购买的那个电子商务引擎？他不可能会像亚马逊自己开发的libido那样灵活。（如果是的话。亚马逊跟那些买了相同产品的竞争对手相比，就没有任何的优势） 购买的网络服务器不可能会跟谷歌自己动手搭建的优化服务器一样快。
This principle, unfortunately, seems to be directly in conflict with the ideal of "code reuse good -- reinventing wheel bad."
这种原则很不幸的看起来似乎和代码复用或者避免重新发明轮子的精神背道而驰。
The best advice I can offer:
我所能提供的最好的建议就是：
If it's a core business function -- do it yourself, no matter what.
如果是核心的商务功能那么无论如何你都得自己动手
Pick your core business competencies and goals, and do those in house. If you're a software company, writing excellent code is how you're going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you're a pharmaceutical company, write software for drug research, but don't write your own accounting package. If you're a web accounting service, write your own accounting package, but don't try to create your own magazine ads. If you have customers, never outsource customer service.
挑选你的核心商业竞争力和目标，这些你都得自己动手。如果你是软件公司，并且卓越的代码是你成功的基石，那么就着手去编写代码，然后去把公司的餐厅，CD刻录外包给其他公司。如果你是一家制药行业公司，致力于为制药研究行业编写软件，因此你不需要编写你自己的财务计算包。如果你是一家网络财务服务，那你就要自己动手实践你的财务计算包，但是一定不要尝试自己动手实现杂志广告。如果你有客户，绝对不要外包客户服务
If you're developing a computer game where the plot is your competitive advantage, it's OK to use a third party 3D library. But if cool 3D effects are going to be your distinguishing feature, you had better roll your own.
如果你在开发一款电子游戏，图形绘制是你的优势，那你还是可以使用一个第三方的三维绘图库。但是如果酷炫的3d效果是你们的核心竞争力，那你们就得最好自己来实现。
The only exception to this rule, I suspect, is if your own people are more incompetent than everyone else, so whenever you try to do anything in house, it's botched up. Yes, there are plenty of places like this. If you're in one of them, I can't help you.
这个规则的唯一例外就是：如果你自己的人全都无法胜任工作。那么不管你什么时候想自己动手实现一些东西，事情都会搞砸。是的，有一堆这样的地方。如果你是其中一个，那我也帮不了你。