DEV Community

Discussion on: On the Occasional Misdiagnosis of "Not Invented Here Syndrome"

Collapse
 
scottshipp profile image
scottshipp • Edited

Joel Spolsky famously wrote a "Defense of Not-Invented-Here Syndrome."

In my career, I've more often seen bad cases of not-invented-here syndrome than I've seen cases like Spolsky mentions. After seventeen years, my personal philosophy about software engineering has developed into the idea that software engineers should do the most simple and obvious thing possible as much as possible, because I believe Donald Knuth's stance that code is actually human-to-human communication disguised as "instructions for a computer." This guideline overlaps with the idea of NIH syndrome in the sense that usually you want to reuse the abstractions people know already so that they can understand what your code does.

But it also doesn't rule out inventing your own something. In fact, it supports it in many cases where a domain-specific language makes the code clearer (and therefore "more simple and obvious") to others.

Collapse
 
ben profile image
Ben Halpern

Ironically, even though I linked to another Spolsky post, this article could be a re-invention of the same basic presence he was outlining.

However, in framing it in my own experiences and cultural context, the re-invention was justified 😄

I really like this quote from that post.

Pick your core business competencies and goals, and do those in house. If you’re a software company, writing excellent code is how you’re going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you’re a pharmaceutical company, write software for drug research, but don’t write your own accounting package. If you’re a web accounting service, write your own accounting package, but don’t try to create your own magazine ads. If you have customers, never outsource customer service.

I think a good takeaway is definitely to know what types of software you should be inventing and don't invent the other kinds, and that is going to be incredibly context-dependent. I think that's probably the issue with these broad statements in general, they require contextual wisdom and framing.

That's why we hang around on sites like this, so we can noodle on the context.