hn-classics/_stories/2001/1583717.md

156 lines
6.9 KiB
Markdown
Raw Permalink Normal View History

---
created_at: '2010-08-07T15:40:03.000Z'
title: In Defense of Not-Invented-Here Syndrome (2001)
url: http://www.joelonsoftware.com/articles/fog0000000007.html
author: aycangulez
points: 66
story_text: ''
comment_text:
num_comments: 44
story_id:
story_title:
story_url:
parent_id:
created_at_i: 1281195603
_tags:
- story
- author_aycangulez
- story_1583717
objectID: '1583717'
2018-06-08 12:05:27 +00:00
year: 2001
---
2018-03-03 09:35:28 +00:00
Time for a pop quiz.
2018-02-23 18:19:40 +00:00
2018-03-03 09:35:28 +00:00
![Copley
Square](https://i1.wp.com/www.joelonsoftware.com/wp-content/uploads/2001/10/Copley_Square.jpg?resize=226%2C195&ssl=1)
1. Code Reuse is:
2018-02-23 18:19:40 +00:00
2018-03-03 09:35:28 +00:00
> a) Good
> b) Bad
2018-02-23 18:19:40 +00:00
2018-03-03 09:35:28 +00:00
2\. Reinventing the Wheel is:
> a) Good
> b) Bad
3\. The Not-Invented-Here Syndrome is:
> a) Good
> b) Bad
Of course, everybody knows that you should always leverage other
peoples work. The correct answers are, of course, 1(a) 2(b) 3(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 didnt
create themselves. People with NIH syndrome are obviously just being
petty, refusing to do whats in the best interest of the overall
organization because they cant 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.
Right. Well, thats 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.
I stopped by Andrew Kwatinetzs 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. Theyll never go for something with so many
dependencies.”
In-ter-est-ing. I hadnt known that. I guess that explained why Excel
had its own C compiler.
By now Im sure many of my readers are rolling on the floor laughing.
“Isnt Microsoft stupid,” youre thinking, “they refused to use other
peoples code and they even had their own compiler just for one
product.”
Not so fast, big boy\! The Excel teams 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 Macintoshs 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.
“Find the dependencies — and eliminate them.” When youre working on a
really, really good team with great programmers, everybody elses code,
frankly, is bug-infested garbage, and nobody else knows how to ship on
time. When youre a cordon bleu chef and you need fresh lavender, you
grow it yourself instead of buying it in the farmers market, because
sometimes they dont 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, isnt honestly adding much value. In fact, if youve ever had
to outsource a critical business function, you realize that outsourcing
is hell. Without direct control over customer service, youre 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 theres
nothing you can do about it, because it took 3 months to find a
fulfillment partner in the first place, and in fact, you wont even know
that your customers are unhappy, because they cant talk to you, because
youve set up an outsourced customer service center with the explicit
aim of not listening to your own customers. That e-commerce engine you
bought? Theres no way its 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.
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 its a core business function — do it yourself, no matter what.**
Pick your core business competencies and goals, and do those in house.
If youre a software company, writing excellent code is how youre going
to succeed. Go ahead and outsource the company cafeteria and the CD-ROM
duplication. If youre a pharmaceutical company, write software for drug
research, but dont write your own accounting package. If youre a web
accounting service, write your own accounting package, but dont try to
create your own magazine ads. If you have customers, never outsource
customer service.
If youre developing a computer game where the plot is your competitive
advantage, its 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.
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, its botched up. Yes, there are plenty of places like this. If
youre in one of them, I cant help
you.
[Discuss](http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=112)