Software development has been around for 70 years and a lot has been done ever since, starting from algorithms and programming practices to frameworks and other abstractions. How can it be then, that time after time we try to reinvent the wheel? Recently I stumbled upon (can’t recall the source, sorry) an interesting term for this: the Not invented here (NIH) syndrome.
I have been there too, of course. About a year ago I thought that all the Object-relational mappings (ORM) for PHP are bloated and full of unnecessary features (a statement I have heard multiple times in past and present by different people). So for my mini-project, I wrote my own extra lightweight ORM that required one to use the same name for entity and table, also entity property names had to be the same as the table column names. The core of my ORM translated populated entitys to SQL and vice-versa. Nothing new here.
Nothing new here
Everything was well while delivering the minimum viable product. I was happy that I could use something of my own making for persisting the entities. As I started my second iteration, I felt that I needed more from my system than I could develop at the moment. I foresaw more required functionality in near future, such as lazy loading and generating database structure from my entities. The NIH-hangover arrived.
As I started my second iteration, I felt that I needed more from my system than I could develop at the moment
I accepted my bad design decision, got rid of my make-shift ORM and implemented Doctrine, that’s still in use today. Fortunately the switch was really easy, since my ORM was easily detachable. This might not be so easy all the time!
My most recent encounter with NIH-syndrome was with a larger Spring project where localization (i18n) strings were stored in the database. The developer implemented the i18n functionality from scratch instead of extending Spring MVC Internationalization feature for database. Justification being that “it was not that hard to implement”. As was my own ORM. This, however, will affect the maintainability of the code. We’d also have to keep improving our own implementation when necessary.
So why do we reinvent the wheel?
So why do we reinvent the wheel? As stated in the Wikipedia article about the NIH: the belief that in-house developments are inherently better suited, more secure, more controlled, shorter development time, or lower overall cost (including maintenance cost) than using existing implementations. Moreover, we tend to think that we can, in some way, reinvent it more elegant, more lightweight and more faster. When in reality the existing implementation has been in development for years by skilled software developers. We should leave the implementation to this team and focus on our business rules!
Moreover, we tend to think that we can, in some way, reinvent it more elegant, more lightweight and more faster
On the other side, we might need to develop something by ourselves, e.g. the existing component doesn’t cover our required functionality and we’d have to implement the missing functionality by ourselves. In this case it is probably for the best if we do not introduce an external component to our system to reduce the complexity. There might also be a licencing issue. But this is rarely the case.
The verdict- NIH is “the ugly”.