Not Invented Here syndrome

Not Invented Here (NIH) is a pejorative term used to describe a persistent corporate or institutional culture that either intentionally or unintentionally avoids using previously performed research or knowledge because the research and developed knowledge was not originally executed in-house.

-- Contributors: MeredithLesly

Discussion

In too many places in Codev, people are unintentionally ignoring previously performed research or knowledge. This may or may not be due to NIH; it may merely be lack of awareness of the research or knowledge altogether. It's still important that areas with (to some) well-known solutions be looked at, rather than trying to reinvent the wheel.

A few examples (please add as thought of):

• The various spam fighting stuff
• RequirementsForMultipleFormSupport (Why do we have backlinks if no one uses it except when requested for examples? Other people can use it too. :mad:)

-- MeredithLesly - 18 Jul 2006

Examples?

-- MichaelDaum - 18 Jul 2006

Well TWiki universally avoided the use of CPAN modules for a very long time, even for the gold standard ones.

To this day this policy includes TemplateToolkit, even though we had Vinod's implementation, and any suggestion of the use of an ApplicationServer.

I've not seen the NIH shortening. How about we rename the topic NotInventedHere ?

-- MartinCleaver - 18 Jul 2006

It's usually abbreviated, but is worded out. That is, people don't say "nigh" or "nee" (perhaps that's where the Monty Python thing comes from?); they say Not Invented Here, but they write NIH.

-- MeredithLesly - 18 Jul 2006

With respect, Meredith, the link to frame based languages is tenuous, and hardly a justification for an accusation of NIH. Rafael has proposed a small, clean change to what exists to support multiple forms. To switch to another representation entirely is a whole different ball game.

NIH usually has a reason. Most of the time it comes about because people want to move forward with what is there today, and not have to re-engineer a whole bunch of stuff to fit with someone else's vision. That was certainly the reason for resistance to template toolkit; sure, you could use it, but for no great measurable benefit, and at the cost of a huge effort to convert skins. Smaller resistances (such as that to some standard perl modules) comes about because of a perceived risk imported with those modules, and a perceived performance hit, as they are often far more functional than TWiki needs.

I'm sure we would have moved to TT (or another template toolkit) if someone had been prepared to put in the huge effort required to change.

As far as I am aware, Peter is taking a proactive role and working with other wiki implementors to imrove spam fighting capability. i don't see a lot of NIH there, though I may just not know the market.

-- CrawfordCurrie - 18 Jul 2006

On TT: In BetterTemplateSystem we learned that TT is slow to initialise, e.g. is not a good fit for plain cgi scripts.

On spam fighting, yes, wiki implementers are working together on fighting spam. It is a fight from multiple fronts with multiple technologies. One additional technology would be using a bayesian filter based on an opens source database, such as SpamAssassin. So, no, I do not agree that our spam fighting suffers from NIH syndrom.

Crawford pointed out some reasons when home grown code makes sense. Here are some additional reasons:

• If you have the choice of creating a specific solution with 50 lines of code, or use a CPAN package of 10 modules with 4000 lines of code, which one would you chose?
  • Straw man. If I had a choice of a module that had been used by a lot of people versus a somewhat smaller module that was rolled in-house, I'd take the former.
• Performance: A small custom solution usually performs better than a large CPAN module (compile time and/or runtime)
• Dependency hell: Installation issue for sites that do not have internet access
  • How'd they get TWiki in the first place? Are we shipping on CD now? How do they get upgrades? How do they get new plugins?
• Skill level of TWiki admin: Installing additional modules to solve dependencies is beyond the knowledge of many TWiki admins. Many never heard of the term CPAN, yet alone know how to install a CPAN module.
  • This is so beyond funny I don't know where to start. People don't know how to configure apache. They don't know how to deal with permission problems. They don't even know how to change the address of the webmaster so that they are notified about new registrations. TWiki is a complex piece of software which requires a lot of knowledge on the part of the administrator, and CPAN is the least of their problems. -- MeredithLesly - 18 Jul 2006

Bottom line: Using external code is OK, but needs to be vetted case by case.

-- PeterThoeny - 18 Jul 2006

NIH doesn't just refer to code. In fact, what I cited above speaks specifically about research and knowledge, not code, although obviously code use applies as well. People have been fighting spam for a long time -- I used to be active in that cause -- and I've seen little evidence that anyone has researched the history, what's worked and what hasn't worked. I could be wrong of course, but do they know about SORBS? ROKSO? Spam isn't just about wikis, you know, even if that's the area you are concerned about. So working with other wiki implementers isn't enough, unless some of the people working on the problem are familiar with the long email battle that continues to this day.

-- MeredithLesly - 18 Jul 2006

And with that, we see evidence for another syndrome increasingly common in the TWiki community. I'll call it the "IKBTY" syndrome (I Know Better Than You). Someone says "I have an idea" or "I have done this", and someone else turns up and says "but someone else did it far better" or more simply "what you did is a bucket of dingo's kidneys". The syndrome kicks in when the commenter can't find the time or energy, or simply isn't polite enough, to back up their comment with links, code or other forms of support that reinforce the soundbite. They leave the commentee feeling irritated, depressed, and faced with a huge research problem to try and build the knowledge the commenter has alluded to. And IME, 7 times out of ten, the comment is a wild red herring anyway, and doesn't bring any real value, just lowered morale.

So instead of throwing SORBS and ROKSO at us, without so much as a google link, how about taking a different approach to the debate; something like this:

The work you did on SPAM is really great, and catches a lot of spam, thank you. In the past I worked on similar problems, and would like to draw your attention to the Spamhaus Project. This maintains a register of known spammers (ROKSO) that can be used to seed a blacklist. Here's a patch for BlacklistPlugin that does this.......

You might be surprised how often an approach like this elicits a positive reaction, rather than a flame war.

BTW this is not a comment directed solely at Meredith. Almost everyone is guilty of IKBTY syndrome at some point, including me.

-- CrawfordCurrie - 19 Jul 2006

I threw it without a link for a particular reason: if someone deeply involved in fighting wiki spam doesn't know what ROSKO or SORBS are without a link, they're not informed enough.

I'm not saying that I may not be guilty of IKBTY syndrome at other times, but in this case it was intentional.

-- MeredithLesly - 19 Jul 2006

Regarding frames, I wasn't trying to suggest we switch to a different syntax. The whole META structure is very much related to frame concepts. And, yes, in theory I could have written a long discussion of this, but I don't have the time or energy right now. (Oh, and I brought this up more about the multiple-inheritance stuff, not the change Raf was suggesting.)

-- MeredithLesly - 19 Jul 2006

I have not been involved in anti spam whatsoever. Still it would be nice to find a few pointers that where thrown in, just to spark my interest.

-- ArthurClemens - 19 Jul 2006

Well, CDot spoiled my "test". the Spamhaus Project is a key player in the current fight. ROKSO lives there. spamhaus.org, IIRC. It may be sorbs.net, but I don't use sorbs and I don't have the time to fighting spam on top of everything else at this point, other than filtering it for my users.

-- MeredithLesly - 19 Jul 2006