Blog

Reinventing the wheel

Any serious software project will be built upon reusable components (usually called libraries) for performing tasks such as parsing and generating xml, network communication and database connectivity to name only those. As libraries for various tasks are readily available for free and for sale, let's take a look at some reasons why one would choose to write one's own instead of using a readily available one.

Let's start with what's undoubtable the worst "reason" for in-house development and is often referred to as the "not developed here syndrome". Companies or departments suffering from it will try to develop everything in-house. At the root of it is generally a distrust of outside developers or the conviction that their own code will be better. There is some pride to be taken in using your own warm water, but it's a step too far to believe no-one else's is good enough.

Don't get me wrong: quality is a valid criterion. You don't want to have your application misbehave because of a poor quality library, but the decision should be based on facts. Unfortunately in most cases you'll have to invest some time to find this out, but so will you if you want to use your own library (which will also require development time).

When in need of something rather specific chances are your search will be in vain. Either no library is available, it's not in the language you need or lacking some feature that is essential to your project. In the latter case you could try to contact the author(s) to ask them if they could implement the missing part (even if it takes some time it will probably still be less than implementing, testing and debugging your own).

Just as finished software comes with end user license agreements, software libraries are subject to licenses that limit the usage one can make of it. It's not uncommon for libraries for which the source code1 is freely available to make it mandatory that all source code for the software using it is made freely available as well. Obviously this isn't an option for any commercial project2. Similarly some licenses (typically for encryption related libraries) limit the countries in which software can be distributed.

While the previous aspects provided a pretty straightforward decision process, price is another matter. For starters, many library maintainers vary their price with the desired service level. Then you'll have to compare that price with the cost for using an in-house developed version. This cost should include development, testing, bug fixing and, hardest to estimate, future maintenance.

Summing up, if a decent library is available with a license you can live with at a price that doesn't send your project cost rocketing sky high, you should probably use it.

1 Programs executed by a computer are in binary (consisting of a sequence of only 0's and 1's). In general programmers write their code in another form (a programming language) that's easier to read for humans, and have a separate program (usually called a compiler) convert it into some binary form the computer understands. The latter is than distributed to end users.

2 If you have access to the source code of a program you can, in theory, find all its internal workings and use those findings to make a competing program.