The interesting thing about not-invented-here syndrome (NIH), is that it surfaces itself in a financial way. Projects end up taking a lot longer than they needed to because some developer or team decided to try and build some solution themselves instead of utilizing reuse.

Digging into this, my experience says it is either one of two things. It’s either a/,  there is truly nothing suitable to make use of (and I’ll talk more about this in a future post). Or b/, the developer or the team honestly didn’t know that reuse was an option, because they didn’t know what was available for them to use.

I want to dive into Option B a bit, because I think there’s an interesting topic to discuss. This is not about “how your organization shares code amongst itself”. This isn’t even really about code. This is about, “why are well-known and solved problems in the field of software engineering frequently ignored”?

I wonder if some of this is the recent de-emphasis of formalized software engineering education. There are so many books, and some of them are actually pretty old, and yet they are all so relevant. I wonder how many current software developers have read the classics, like Design Patterns: Elements of Reusable Object Oriented Software, or Code Complete, or The Pragmatic Programmer, or The Mythical Man-Month. I wonder how many current software developers would scoff at the thought of reading those books, or conversely how many have read them and thought, “Oh wow, this book is very relevant and useful!”

I’m sure there are plenty of modern books, blogs, articles, podcasts, etc., that cover the same types of topics. But in the modern professional world there’s probably a challenge with finding the time to find things and then actually read/listen. If you are a modern technical business leader, allowing your technical staff some small amount of time each week or month for these types of professional development activities is actually worth it financially, because it reduces the risk of the financial impacts of cost and schedule, because your developers will be more knowledgeable on HOW to solve problems, which means they can get to the implementation phase faster and with less rework.