NIH – Not Invented Here Syndrome

We've all seen it, we've all been stuck in it. You look at an application, a widget, a feature, or a class and you think “Why did they do THAT? I could do this much better myself!”

Quite often you might be right. There is all kinds of crap code out there. No way to deny it, there are developers out there who haven't bothered to subscribe to any coding standards, standard operating procedures, or habits, and don't even bother looking for any sort of rigorous testing or documentation standards. It feels like fingernails on a blackboard to look at it, let alone make changes to it. But then there is the extreme opposite.

There are beautiful applications, code, and libraries that you look at and marvel. You know the code I'm talking about. You didn't expect to see it and you opened the source and thought “Oh, that's nifty.” Then you thought about making a change or writing an Adapter Pattern to add functionality and you realized that either you didn't have to or the Adapter Pattern took 2 minutes to write.

Unfortunately, it seems that most code falls somewhere in between and you can't even tell what end it is on until you delve into it deeply and hit your first brick wall. You stop and think, “Well, I'll just re-write this class/module/feature and it will be much better.” Well, maybe…

I'm in a situation now where my boss (not CEO) wants a CRM application. I recommended SugarCRM – after all, I secretly deployed it for the Business Development people a month ago – but he said that we must write it from scratch. I am unsure as to how this requirement exists as their has been zero requirements gathering but it does. Therefore, we must pass on using any of the SugarCRM framework and develop our own from the ground up. This does not seem like an efficient use of resources, but I guess since this is not a cash-strapped startup there are other people footing the bill and this will be utilized to its fullest.