Are you afraid to write code? Does the thought linger in your brain that somewhere out there somebody has already done this? Do you find yourself trapped in an analysis cycle where nothing is getting done? Is your product mutating to accommodate third party components? If yes, then perhaps you are suffering from invented-here syndrome.
Most of use are aware of not-invented-here syndrome, but the opposite problem is perhaps equally troublesome. We can get stuck in the mindset that there must be a product, library, or code sample, that already does what we want. Instead of just writing the code we need a lot of effort is spent testing out modules and trying to accommodate our own code. At some point we need to just say, “stop!”, and write the code ourselves.
Varying levels of quality
As a general rule it makes sense to not write code that already exists. Often the choice is easy. We just pick up a standard product, lump it in with our code, and it just works as promised. These situations are great, and do happen often enough.
Past this come the less than ideal choices. Perhaps a library covers only 95% of the requirements, configuration is a bit more involved, or the purpose has to be twisted a little bit. It’ll work, but not without some effort, or rethinking a few requirements.
At some level we enter the realm of crappy products. These are things advertised to do what we need, but fail utterly at that task. Or perhaps they just do something in a completely different way than expected. Maybe the integration is extremely troublesome. Perhaps the product is just too bug ridden to be trusted, or the documentation so bad that proper usage is a mystery.
From what I’ve seen, the vast majority of coding products, snippets, or libraries fall into this category of crappy software. Being available in a package manager, being downloaded by thousand of people, or having a fancy web page, are no indications of a good product. It’s trivial to publish programming products nowadays. Chances are for any obscure requirement there is already some matching product. Just because it’s there doesn’t mean it should be used.
I should point out that the vast majority of any project is comprised of standard products. Just consider the operating system, the compiler, file system, shell and the build system. Add to this the excessively common, or even builtin, libraries like SSL, HTTP, or simply using the browser to render HTML. The fear that a project is not using enough standard components is often misguided.
It’s about the time
It shouldn’t take long to discover when a required module doesn’t exist. Sure, there are products but either they are far less than ideal or just too crappy. New search terms are either coming up empty or returning the same results. Lists of popular, seemingly suitable products, just don’t include any that really fit. That’s it. The search is exhausted.
I’m not saying we should immediately jump from here to writing our own module. No, now is the point where evaluation becomes important. Time is usually the critical factor here. How long will it take to write a custom component? How long will it take to adapt one of the existing products?
I feel that the time savings from using a less-than-suitable third party product must be an order of magnitude higher than writing it myself to consider it worthwhile. Third party code has a lot of open questions, regardless of how well it has been evaluated. This uncertainty must be factored in to the consideration.
Getting stuck in analysis paralysis is very bad. I have no problem writing code prior to completing the analysis. I consider this a valid form of evaluation. Often I’m not really certain what I even need until I’ve attempted an implementation. Stalling a project can often be disastrous. Perhaps my quick code is just enough for now and let’s us defer the decision to later.
It’s about the features
One trap that’s easy to fall into is looking at the full feature set of a product during evaluation. Who cares about everything a product can do. Our project has a specific list of requirements, and those are the only requirements we should care about.
This is where a lot of popular products falter. They offer a complete package, but we simply aren’t looking for a complete package. Sure, they have the feature we want, but there’s no way to efficiently extract it. We need to view the individual features on their own. This is relevant to the time consideration. Clearly product Xyz would take millions of man-hours to recreate, but perhaps module Q will only take a few days.
A second aspect here is how vital a requirement is to our own product. Compromising our key selling points is going to doom the project to failure. There’s no value in saving time if it doesn’t result in the intended product. We just have to face reality sometimes: getting the desired feature set may involve writing a lot of code. We’re programmers though so that shouldn’t scare us.
Warning! Being delusional here is not helpful, and can often lead to genuine not-invented-here syndrome. Most features can be realized in many different ways without changing the substance of them. The time invested to write a feature exactly as we want has to be related to how critical that feature really is. It’s best to involve marketing, or product management, in such decisions. It can be easy at times to lose sight of what is truly important.
Write some code
Fretting over a selection of inadequate products is not productive. While it’s entirely reasonable to avoid not-invented-here syndrome, becoming overly frightened of writing code can land a project in a production quagmire. It shouldn’t be surprising that software development involves actual coding.
A great mass of libraries, modules, code, and other software products, available on the net are either crappy in their own right, or simply not suitable to our project. Forcing things to work together can be costlier than simply writing the required code on our own.
And what if coding turns out to be wrong choice? Well, that’s part of development. It’s quite possible attempting our own component actually leads to the correct third party product. Since we’re following good design practices it won’t be a huge problem to swap components in and out as desired.