Page 216 -

Another important reason that changes may seem uncomfortable is that the people in the
organization may not fully understand how the software is built. Many senior managers
have a great deal of experience with the problems that the software solves: for example, the
CEO of a company that builds financial or accounting software knows a lot about finance or
accounting. But, frequently, the details of what is involved in building the software are a
mystery to them. When senior managers are disconnected from the design and develop-
ment of the software, they begin to see it almost as a “magic formula.” They are clearly mak-
ing money selling software, so they must have made the right decisions. Now some project
manager is coming along and telling them to make changes to this formula, which they
don’t understand. A senior manager does not like feeling ignorant of his own organization,
and he does not like being told that the organization that he built needs to be fixed.
Ironically, in many organizations where people claim that they already build software well,
there is no standardized way of building software. Sometimes there are requirements writ-
ten before the programming begins; other times, there aren’t. Sometimes there is a project
schedule, but often, there’s just a single deadline. In one project, the software may be tested;
in the next, it’s dumped on the users. Since no two projects are ever done the same way, it’s
always true that the team has “never done it that way before”—and this excuse is still used
to shoot down anyone trying to come up with a way to build better software.

“Not Invented Here” Syndrome
“Not Invented Here” syndrome (NIH syndrome) is a name given to a common type of
organizational culture where people intentionally avoid research or innovations that were
not developed within the organization. When faced with a problem, the people in the
organization will typically reject a solution that is known to have worked elsewhere in the
industry, solely on the grounds that it did not originate from inside the organization. They
opt instead to build their own solution, often at far greater cost.
This may seem ridiculous or silly to people who have not directly experienced it, but NIH
syndrome is a serious problem. Some teams will waste many hours defining procedures,
creating tools, and building their own solutions to problems that have already been solved
elsewhere, rather than adopting or adapting an existing solution that can be purchased off
the shelf or learned from a book, training course, or outside expert. One motivator behind

NIH syndrome is that people are often rewarded for building new software when they
would not be rewarded for buying something that does the same work. For example, a
programmer who would get a lot of recognition for spending months building a compo-
nent might not get any recognition for buying an equivalent one, even though it would
cost a tiny fraction to buy rather than build.

If you think about it, you may recognize at least a small example of this behavior in your
own organization. For example, many programmers will “reinvent the wheel,” building
functions or components that could be purchased or downloaded. If your organization
commonly develops proprietary technology instead of using an alternative that’s available
from a third party, it may suffer from at least a mild case of NIH syndrome.

208 CHAPTER NINE