NIH Syndrome

  • Article

NIH = Not Invented Here

So here at Microsoft we have a lot of really smart people.  Unfortunately that seems to lead to a lot of NIH syndrome.  That really wouldn't be so bad if we had a broad enough definition of 'here'.  For me as an individual developer on my spare time, I'll reuse just about any pre-existing source that I can legally use for a reasonable price.  That includes 3rd party binaries at least until I prove them to be buggy, inflexible, or unsuitable for my purposes.

Here at MS you would think a reasonable definition of 'here' would be anything within MS.  The sad part is a lot of people define 'here' as simply themselves: if I didn't invent it, it must somehow be inferior to what I would have invented, and thus I would be better off to redo it myself.

In my 5 years at Microsoft and limited college experience I've seen several different build systems.  Just to name a few: classic makefiles, shell scripts, GUI-based 'projects', Microsoft's own build.exe (which is built on top of nmake and makefiles), NAnt, XMake, and now I've heard for whidbey the VC project system is going stand-alone (so you can build VC projects without the IDE, kind of like XMake is doing for C#) vcbuild.exe

That's quite a few.  Now here's the sad part: several of these different build systems are used here at Microsoft.  Some of them are even mixed together to build different parts of the same product!

Now unless your product really is supposed to be a build system (like the XMake team or the VCBuild team), why would anybody at Microsoft invent a new build system?  To answer my own question: NIH Syndrome.  Just to prove that NIH is alive and kicking I have discovered more evidence of new build systems being invented by non-build-system teams!

The good news is that at least this isn't limited to developers.  There are actually more testing harnesses than there are build systems.  I only know that because of how hard it is to deal with bugs from other teams that the repro is “run this test in our test harness”.

Hopefully I never get NIH syndrome.

Open source could be the answer to NIH Syndrome, because I suppose that way everybody who cares feels like they had a part in inventing something.  However, that can't be totally true because there are several competing efforts even within open source.  If it were, it seems like eventually all the really good features would get ported into the better product and the inferior one would just disappear.

Does anybody know any antidotes?

--Grant

Comments

  • Anonymous
    June 03, 2004
    It seems to me that you need a person (or team) whose full time occupation is to promote and enable code reuse in those situations. It would be both a marketing campaign as well as a technical imperative.

    Especially with Microsoft's seeming focus on "dogfooding" their own products. Why should I use MSBuild if MS isn't using it internally. If teams within MS feel they need a custom build system because MSBuild doesn't work for them, then I would be skeptical that MSBuild will work for me.

    Likewise, I think extensibility is another important factor. MSBuild is very extensible, so it likely would work for nearly any team. They should focus on extending that platform for their usage and not reinvent the wheel time and time again.
  • Anonymous
    June 03, 2004
    The comment has been removed
  • Anonymous
    June 03, 2004
    Oh, and btw, all the avalon code in Longhorn is built with msbuild as far as I know.

    There's other managed code that's built with the standard ntbuild build environment but the avalon stuff's built with msbuild.
  • Anonymous
    June 03, 2004
    The comment has been removed
  • Anonymous
    June 04, 2004
    NIH can also show up for a number of reasons. You mention developer arrogance. Larry mentions lack of functionality. Eric mentions bugs in implementation. There's also a lack of knowledge about other options, unwillingness to pay for (or pursue) other options, fears about usage rights, and lack of trust in external code.

    The only cure I've found is a complete review of the alternative solution. This includes a code review if code is available. The process can be a pain and deemed not worth the total cost.

    I wouldn't say Open Source Software suffers from NIH as much as any given piece of code may not totally "scratch the itch" the developer has. This is one of the plusses to OSS. A developer can take existing code, modify it for their own purposes, and give the code back to the community if they are distributing the new binary externally (otherwise they're free to keep the change to themself). Certainly there is some NIH in OSS, but this can only strengthen the overall pool of solutions to a given problem.
  • Anonymous
    June 07, 2004
    Ron writes: "Certainly there is some NIH in OSS, but this can only strengthen the overall pool of solutions to a given problem. "

    This is certainly a strong point. I just took a look what's been happening on a "dos/x86" emulator called DosBox. While do not have many developers on the quite ambitious project, they have still managed to add protected mode support and bunch of sound card emulations and what not, which seemed quite "impossible" not long ago - due to developments in other open projects and help from their authors.
  • Anonymous
    June 14, 2004
    guilty as charged

    I am probably one of the world's worst NIH addicts. If something, even the littlest thing, bugs me about another developer's implementation of something, I cannot sleep until I have rewritten it.

    I don't chalk it up to arrogance, because I know my limitations as a developer, and will often use ideas pioneered by others to accomplish the goal. I don't think there is a cure, either. I'm hopelessly incurable, and even rewrite my own code. It helps me think... I think. :)