Whenever possible, steal code.
– Tom Duff, Bell Labs, quoted in Programming Pearls
“Not Invented Here” (NIH) is another fundamental concept in that one must understand when entering software development. NIH describes the tendency of an individual or organization to refuse using an available solution (say, open source software) just because it was not invented by them (hence, not invented here).
There are a lot of issues and concepts related to NIH (as seen in the WikiWikiWeb page) so I’ll only cover the basic concepts in this post.
—
The first time I read about NIH is in Alistair Cockburn’s Agile Software Development: The Cooperative Game. There is something about Cockburn’s (pronounced Co-burn -___-) approach to NIH that separates it from the other perceptions of NIH. Unlike those who add “syndrome” at the end of NIH, he treats NIH not as a disease but as a cultural imperative. That is, people and organizations practice NIH because their culture trained them to do so from an early age.
From earliest school days, students are instructed not to copy other people’s work, to not help each other, and to be as original as possible in all but rote memory acts. They are given positive marks for originality and punished for using other people’s solutions. (Recently, a fourth grade teacher told her students not to call each other to discuss homework problems—not even to ask for which problems to do!).
Through the university level, assignments are designed to produce grades for individual work, not for teamwork. This reaches a culmination in the Ph.D. dissertation, where originality is a core requirement.
Somewhere in these years of schooling, some people join the profession of “programmer,” a person whose job is to program and who advances in the profession by writing harder and more uniquely original programs.
Under these circumstances, it is hardly surprising that the people internalize the Invent-Here-Now Imperative.
If you’re unfamiliar with software development, you might ask:
So what’s the problem with striving for originality?
For software engineers, the answer is simple:
It’s usually a waste of time and resources.
Modern software development is different from school. When an English teacher asks you to write a short story and you copy one off the net, you’re a plagiarist. Depending on your educational institution, you could be expelled for that act.
On the other hand, if a client wants you to set up a CMS for his company and you use Joomla, Drupal, or whatever open source CMS for it, you’re a pragmatist: you just saved thousands of hours of development and testing when compared to writing one from scratch.
—
That said, I’d like to point out two things related to NIH:
First off, it does not mean that “code reuse is always good” and “NIH is always bad”. In fact, Cockburn’s reason why he mentioned NIH in the book is not to condemn it outright, but to show us the importance of researching over inventing.
This means that, when faced with a programming task, a software developer must first research for the simplest solution available. It may be in the form of a built in function or class in her framework, or it may even be someone else’s code. A developer would only code everything from scratch is if the task is trivial and disposable, or if the effort of researching (or modifying, if a third party module is used) in both the short and long term is larger than coding from scratch.
—
The other implication of NIH is that it exposes the fact that traditional teaching methods (i.e. those used in computer science courses in college) is not conducive to producing quality software developers needed by the industry.
I would agree that computer science should program their own MPs instead of copying from their classmates (speaking as the-guy-who-never-copied-code-from-anyone, I personally found this behavior insulting back in college). But the problem here is that throughout a computer science student’s life in college, the student is taught to value originality as they are valued in other courses.
By adopting an NIH culture, computer classes continually promote values that are considered detrimental in software teams: independence instead of teamwork, pride over one’s own work instead of open mindedness towards other solutions, writing throwaway code instead of writing maintainable code, etc.
Now you have an idea of what I have to deal with when I was a trainer for my previous company. :P
