I recently read about the new face of NIH syndrome, and after sharing and discussing it with some coworkers (Hi, John!) I had some thoughts about how NIH (or what Freeman calls NPF) comes to be, and what it means about an organization.

For the uninitiated, NIH stands for “Not Invented Here,” and refers to the inclination of some development organizations to avoid third party tools at all costs, because there’s some sort of vague FUD (fear, uncertainty, doubt) around using anything that our developers haven’t written. Maybe it won’t work, maybe it won’t work *well*, maybe it will stop being supported, etc, etc. Freeman argues that the software industry has, by and large, rid itself of NIH syndrome, but it has done so mostly through word policing and social mores, and developers still do roughly the same thing, only in the form of what he calls NPF: Not a Perfect Fit syndrome. The symptoms are the same, more or less: sure, this software works, but we realllly need X feature, and no one else does that. Or, yea, that works, but do we really want to deploy a JVM on our wiki box? why not just write our own? Or, etc. Same symptoms, same cause, different name — because saying “we can’t use that, we didn’t write it” doesn’t work anymore, you need a plausible-sounding justification, however thin it may turn out to be.

So I was reflecting on all this and chatting with John, who is a wonderful sounding board and generally a thoughtful person, and I mentioned that I have basically no vulnerability to NIH, at which he looked slightly surprised. Upon further thought I have come to think it is because I don’t find all that much joy in writing code. Sometimes it’s fun, and certainly the feeling of solving interesting problems is always rewarding, but I am much more motivated by delivering value to customers than by just the raw act of implementing things. I’m currently really excited about an upcoming project at work because I had spent a while worrying that it would turn out to be frustrating and difficult for customers to use, but after some recent discussion I realized that we have the opportunity to turn it into something that customers will really like. That is so much better of a motivator for me that I can’t imagine slowing down the time to get that feature out to customers by banging out a proprietary form validator or whatever.

And so now I come to my main point: many developers in many companies are basically not permitted to have the kinds of motivations that I have, the ones that supersede the mere technical challenges. Many organizations silo off their development teams, both from the business and, often, even from each other. They are handed feature requests from the business, largely devoid of context, with little idea who they benefit or what the underlying goal is. I consider this a form of infantilization, honestly: the only reason to do this is because you think developers need insulation from the scary business types that poor nerdy coders can never figure out how to interact with effectively. They can play in their little sandbox while the adults gather requirements and decide what to have them do. In this environment — and, actually, I have worked in conditions like this, although not for long — it’s easy to see why someone would develop NIH syndrome. If your job is to do context-free drudge work updating some winforms or CRUD app or whatever day in and day out, and you don’t see customers loving it or understand why anyone would need it, of course you’d make up any excuse to do more interesting work. If the only motivation you’re allowed to have is “for the love of the code,” then the best you can do to keep yourself interested is to work on more interesting code, since you’re not allowed to help solve more interesting business-related problems. Given that the only tool I have for working on an interesting problem is telling someone who wants me to work on a boring problem that there are important prerequisites to it, and that none of the existing solutions to those prerequisites will work for our special snowflake case, I am going to use that tool constantly. If my choices are “write a Django clone” or “write an intranet CRUD app in Django,” I’m going to choose the former every single time.

I am lucky enough that those are not my choices. First of all, no one I work with would dream of letting me write a Django clone, thank god. Secondly, and more importantly, my choices are more like “work on this feature to help customer X” or “work on another feature to help customer Y.” I’d rather do either of those things than write a Django clone! I’ve talked to our customers, I know the pain they feel, and I know the value they can get out of using our product, and helping them is great. Creating a product that I can feel good about giving to customers is a much better feeling that knowing I’m capable of writing some tricky library from scratch.

(Hopefully unnecessary disclaimer: some developers are more motivated by the writing of tricky libraries than the helping of customers. This is totally fine and I don’t mean to deride it in any way. I’m talking about the developers who are like me but not given the freedom to work on projects that would be interesting to them)

There are obviously other reasons an NIH mentality can take over a dev team. “Job security” is a shitty reason people might do this, a feeling of fear that we either can’t implement what we need to or don’t know what we need to implement is a much-less-shitty reason. But I think this explanation explains a lot of the organizations that get taken over by NIH syndrome, and I think it’s a particularly pernicious reason.

It’s pernicious for two main reasons. The obvious one being that you’re wasting your developers’ time, or rather letting them talk you into wasting their own time. That’s just an unnecessary inefficiency in your organization: you would literally be better off firing them.* The second one is that this kind of environment is only appealing to developers who are happy just hacking out code without caring about the business. Engineers who do have any interest in being an active part of helping your customers are going to be frustrated and leave, and the only ones left will be incompetents who can’t find another job and ones who only care about technical chops and have no qualms about crying NIH constantly in order to scratch that itch.

Do you really want that? I mean, empirically, the answer is yes, a lot of companies do want that, because they choose to infantilize their engineers. But you can do so much better! You can get feedback from intelligent, knowledgeable parties, constantly. You can motivate engineers by introducing them to the customers they’re going to solve problems for. You get everyone more involved and more motivated! And you don’t have to constantly fight with your developers if you treat them as grown ups; they won’t constantly scramble to justify NIH tendencies because they’re engaged in their work, and they’ll get more done, and they won’t be incentivized to bullshit you about what can or will get done, and everything is just so much nicer.

In the end, my point is basically just “treat everyone in your company like an adult,” which seems like it should not be controversial enough to say nor rampant enough to break down into sub-categories of infantilization. Unfortunately we do not live in the best of all possible worlds.

*They would probably be better off if you fired them, too! Imagine a person who develops an internal bug-tracking tool because Jira is “not a perfect fit.” Now imagine that person works full time on this Not-Jira, or, say, full time for 3 months and then ~20hrs/wk indefinitely. Let’s say you don’t fire them: you’re wasting ~half of this dev’s salary (half of their salary – a monthly Jira subscription), and this dev is wasting half their time on non-transferable skills that will get them nowhere in their career and severely limit their job opportunities moving forward. Or don’t imagine it: I have seen this exact situation transpire, maybe you have too.