Avoid Or Embrace Libraries

When should we avoid third-party libraries? When should we embrace them?

"Embrace and extend!" -- MicroSoft ;->

In the build-or-buy situation, I recommend BUY, BUY, BUY! If you can buy a 3rd party package that meets your needs, do so. It's a no-brainer, just buy it. -- JeffGrigg

The higher-up the libraries affect your core functions, the more I say avoid them - if the vendor changes its model of support, or the functional model they wish to support, you're in trouble. -- PeteHardie

For me, it's a case-by-case basis, and I start by asking myself "How common are the things that I need out of this software?" If my needs are very close to other people's needs, chances are good that the market has had enough demand for someone to create a robust, well-maintained library. If my needs are extremely particular, the chances are much smaller.

This is a very good point, the library must be suitable. I have seen people shoehorn a library to make it do something it wasn’t designed for. An example I remember well is someone who wrote about 50 lines of call back functions and signal handlers to use a comms. product to poll the status of a connection, whereas the same thing could have been achieved in 15-20 lines of simple code.

The strange thing was that even though the misused library code never worked properly (it would occasionally miss a signal and hang) it was six months before the project manager would let me replace the code with something that worked. His excuse was "group XXX uses the library and they have no problems". Of course, group XXX were using the library for transactional processing, which is what it had been designed for.

That is my experience of EJB's.

Another experience is that the project manager says "group XXX uses the library and has no problems", so you have to use it. A few months later, you actually talk to members of group XXX for the first time, and they tell you they've had nothing but problems with the library and can't believe your group chose to use it.

If I use a vendor library, I can change my mind later, and replace the library with custom code. But if I start with custom code, there is practically no chance that I'll ever be able to replace it with a standard library. -- JeffGrigg

I agree that BUY, BUY, BUY usually is a no-brainer. The costs of buying are almost always lower than those of building. But it's also important that you be willing to throw the library away and go with plan B if it turns out to be a problem. Don't stick with a bad library just because you paid a lot of money for it or had to fight to get it purchased. It's a SunkCost. -- KrisJohnson

Code for core functionality I prefer to develop in-house. It may take a bit longer, but if it's a key technology, the team needs the sort of understanding that only comes from developing an implementation.

In the build-or-buy situation, I recommend BUY, BUY, BUY!

Yes and no. I've had to use 3rd party stuff and then had the 3rd party: 1) go out of business, 2) decide to stop supporting a platform, 3) decide to dump a product altogether and refuse to sell the source or legacy license.

I'd have killed for a copy of the phdBase source. It solved a text search problem for us in an elegant and transparent way - until the OS and language versions changed. Boo hoo. I had to re-implement the concept using higher-level language features rather than an API library. I got it to work (and work well) but it cost me months.

Having the source code is the best insurance. If the 3rd party will provide it, then at least you have a fighting chance. -- GarryHamilton

I'll go out on a limb here and say BUILD BUILD BUILD! Give me the ultra tight fit, lowered complexity and increased system knowledge of a well-written custom-coded library over a purchased product any day of the week.

Think about the cost you pay for the 3rd party tool:

support costs
research costs to decide which tool to use
work arounds for bugs in the tool that you can't fix because you can't change the source
overhead of dragging around all the garbage you don't need in order to gain a subset of features that you do need
lack of understanding of the deep mechanics of the tool causes incorrect usage
possibility of suddenly losing support for the tool
obviously - the cost of the tool itself
very high license renewal fees on some software

etc etc -- JeffBay

However, many of those costs are amortized over many customers. If you build-build-build, your company shoulders them alone.

However, the company that is selling the software is trying to make a profit over many customers. Frequently, a very large profit margin, indeed. -- JeffBay

See: NotInventedHere, BuyDontBuild