The software house and the farmer’s market

The “Not Invented Here” (NIH) syndrome has been around forever, in all sorts of domains. For those of you that have somehow missed it, it simply describes the predisposition to favour local implementations of functionality that are already available elsewhere. It stems from lack of trust – anything developed elsewhere will be buggy; insufficiently documented; poorly supported; and, quite simply, not exactly what we need – and ignores the fact that writing something in-house often leads to a product exhibiting similar negative qualities, while also sucking up precious time that could have been spent doing something original and valuable.

Compare this to an upsurge of interest in local produce of all varieties. Farmer’s markets are thriving. Bars offer a selection of drinks from local micro-breweries. Supermarkets proudly proclaim that some of their produce is sourced locally.

Some of the desire for local food can be seen in the same light as the mistrust that often fuels NIH. Doubt about the production methods of large agro-industry, for example. Some can be attributed to environmental issues, such as food miles, or specific nutritional factors, such as degradation from time of harvest. But some, surely, is due to a sense of physical community. Local food is produced by people who live near you. There is a comfortable (and yet unfounded) assumption that local producers act more ethically, that they don’t do any of the ‘bad’ things that some less local producers do. In short, that we can trust them. We may construct rational reasons that justify our trust, but they only serve to conceal its underlying subjectivity.

It is frequently the same subjective processes that lead to software shops reinventing the occasional wheel. We naturally assume that a local team is more responsive than a remote team. That you can go talk to the team that maintains the library to ask if it supports a specific use case; to figure out if the problem really is a bug; to request new functionality. My experience, however, is that this is generally an incorrect assumption.

If the component being considered isn’t part of your core value proposition any NIH arguments should always be resisted. Good engineering practice dictates that every 3rd party component is only accessed through a local wrapper that provides the precise functionality required in your context. If the component later proves to be unsatisfactory you can replace it with another one, or develop your own replacement. Anything else is premature optimisation – unnecessary and probably harmful.






Leave a Reply

Your email address will not be published. Required fields are marked *