It's tempting, when designing Object Oriented systems, to abstract not just code that you know you want to reuse in the project, but also code that 'you might want to use one day'. Similarly, in some disciplines there still appears to be a ''blind'' "reuse before rewriting" mantra. It's also common to get carried away with designing for everything.
This article summarises factors when considering whether you want to use existing libraries or write your own, and whether it's worthwhile writing reusable code. I'm assuming that you already have some idea of the effort it will take to write your own to compare with using existing libraries.
It takes time to evaluate existing COTS systems. They not only need to be investigated to see if their features match your requirements, but also tested to check that they really do, and to check the quality of the product. One of the expected benefits of using COTS products is that they have been already 'proven', but you need to check that this is really the case. Has the version you're intending to use been used elsewhere? Who by? Are they using it the same way that you intend to - ie, are the paths through the software going to be similar? Will problems they've encountered be more or less important to you?
Estimate effort to install & configure, and compare. What features are missing? Who can implement them? Are they available? How much will it cost, how long will it take? If many features are missing, is the library a suitable starting point?
Some reusable libraries will need to be configured to your particular requirements. Beware of libraries that require considerable configuration in a bespoke language - they will require specialist skills (making maintenance more expensive). General solutions are always bespoke at some level. There comes a point where configuring some systems becomes so complex that the effort outweighs writing code - which after all, is the ultimately configurable application.
In particular, when looking at systems that will need considerable configuration, check the documentation and how errors in the configuration will manifest. Blind trial-and-no-error reconfiguration is frustrating to the victim and sucks up time and effort from a project.
Any code library will require time to learn. What is the documentation like? Is it going to take days of experimenting to get it to work, when a single day knocking up a perl script will do the same job?
What are the long term benefits/hazards of both - ie, if you can get a COTS product running and keep the skillset alive, then it may reduce the maintenance load over the next few months or a year. If this is a once-in-six-months operation, then you may face having to get someone to relearn all the skills six months later, as opposed to working through a bit of code using a commonly available and transferrable skill.
Where you maintain your own libraries you will need to assign effort for fixes and improvements to handle new technologies. Where you are using other peoples, can you count on them to fix things promptly? Is it likely to be developed further? Can you influence delivery if necessary?
Remember that reusable software tends to be larger and include more abstract comcepts than bespoke. This in turn requires more maintenance effort, and the consequences of making changes to shared code can be Bad (if it affects using code unexpectedly) as well as Good (if it fixes bugs whereever the code is used)
It is tempting to factor out common code in different components. This requires estimating the effort in doing this and the savings in maintaining the single common code, against the refactoring and how likely the common code is going to stay common.
Common code must be very carefully maintained. A new feature requried by one common-code user must not break any other users, no matter how many there are of them, or even whether you know of them or not. ((VersionControlPractice|Versioning libraries)) can help.
When looking at using 3rd party libraries or COTS products, consider:
Both a kind of re-use; consider assembling parts of a product rather than using and customising it.
I worked on software to help data owners publish their data to the web (and the [http://www.ivoa.net|Virtual Observatory]). In other words, I was working on writing reusable software in java, in the form of a customisable webapp (eg SkyCatServer) and a set of libraries (Publisher's AstroGrid Library) that could be used to help write a webapp.
I shudder to think how much effort I spent in doing this; as you do, I got quite involved in making the software easy to install, configure, and fairly feature-rich to encourage data owners to use it. However most data owners are at least passingly familiar with web technologies and are quite capable of writing their own using their own favourite platform.
Usually the data was published from an RDBMS to the web with a particular web interface. This activity typically takes a few days with a suitable platform (such as .NET). The result is that I spent a vast amount more effort writing a reusable solution than adding together all the effort of installing bespoke solutions at each site.
[Writing a general solution was a side effect rather than the main remit. I was to investigate the various possible publishing solutions (including non-RDBMS data) and feed these into the IVOA interoperability and standards processes. The PAL libraries captured some solutions in software, and the SkyCatServer helped to test them in practice. However it serves as an example of when not to write for reuse]
The mantra "Let's not re-invent the wheel" is sometimes used to mean you shouldn't build your own wheel.
Other wheels may not be appropriate; you may want one with a specific hub, spoke length and rim. Or you may want a racing car wheel.
But we know how to build a wheel - we can build one without re-inventing one, as long as you know how and if you have the right tools; ie have the skillset and toolset. [an error occurred while processing this directive]