NIH Syndrome


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 (10)

  1. 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.

  2. This isn’t entirely true.

    For example, each of the 20 or so component teams that made up Exchange had their own build systems. The build lab had to manage all of these and come up with a single coherent build. It was an absolute unmitigated nightmare.

    So for Exchange 5.0, we started looking for a new build system. We went and worked up a set of requirements for the build system and started asking other teams around the company.

    When we got done, we realized that NONE of the existing build systems would work for a product as diverse as Exchange (We had to be able to build NT, Win9x, Mac and DOS clients, for example). So we ended up writing our own build system based on nmake with a bunch of perl scripts. It’s actually a really nice build system to be honest.

    So sometimes you don’t redo the build system because of NIH, sometimes you do it because you don’t have a choice.

  3. 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.

  4. Eric Newton says:

    i suffer from NIH a bit sometimes, its mostly because of a major flaw or a major weakness in the other dev’s implementation really *REALLY* bugs me to the point where when I try to work within the framework presented, I run into a dead end because of an internal class or an internal protected abstract method that cant possibly be overridden by anybody outside of the assembly [which I think is the incorrect protection level]

  5. Ron says:

    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.

  6. Joku says:

    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.

  7. Sean Terry says:

    *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. 🙂