Succumbing to NIH is a Risk

Tags: devops programming

I’m evaluating OpenStack commercial partners, and I’m interested in their ability to blend with our current infrastructure. One vendor touted their automatic provisioning and configuration management system, and I wondered if it was just a re-brand of something like Puppet or Chef under the covers. Puppet would be fantastic since we’re invested in that technology already.

Google pointed me to a clarifying article:

… [PRODUCT] doesn’t rely on third-party products such as Puppet or Chef to handle deployments. He claimed there was risk involved with using such tools, especially with Puppet’s ties to VMWare, and suggested the learning curve was higher using them than with his company’s package.

Risk happens. We dance with risk all day every day. With no more specific information regarding the risks inherent in using an existing provisioning and configuration management system, I must assume those same risks are present using their home grown system. Nobody from Puppet Labs will stop by the home office of this vendor and demand exclusive use of VMWare hypervisors. The vendor is still free to write their own Puppet modules for managing their OpenStack implementations. The vendor is free to ignore Puppet all together while still choosing a completely competent and capable configuration management tool already in use by the community.

Concerning the learning curve problem, there’s only one explanation that makes sense to me. I think he left out some words. I think he meant something like “… the learning curve [for him and his PRODUCT team] was higher using them than with his company’s package.” That makes much more sense to me. It’s a tale as old as software development. I’ve seen it in my own lifetime more than I care to remember. It’s called NIH Syndrome, and it goes a little something like this: “we don’t have time to learn [INDUSTRY STANDARD PACKAGE], so we’re going to write our own instead.”

Because ignoring thousands of person hours worked by experts in the field of that tiny portion of the domain will surely pay off in the long run when your small team of generalists attacks the same problem for two weeks.

I’ve also heard trust arguments against existing components. “We didn’t write it ourselves, so how can we trust it?” Right. A package in use all over the world is obviously untrustworthy. That’s why I write most of my software on a custom home built computer that I soldered together myself. We’re going to need to make a bulk transistor order from Radio Shack so I can build enough equipment to run at scale. It’s the only way to be certain.