Where would we be, as programmers, without third party libraries? We'd be in the freakin stone ages. So they're important, very important. It's also important to know the right time to use a third party library and that's what I'm going to talk about here. Please feel free to leave comments so we can all learn from each other.

Let's make sure we're all on the same footing here. You're the programmer on a project made for a customer. The project has users, who may or may not be related to the customer. As far as the users are concerned, they are using one piece of software: yours. In reality they are probably using a couple dozen layers of library code written by other people topped off with a thin layer of customization that you wrote. If that doesn't give the customer a nice warm feeling I don't know what will.

Third party libraries can include but are not limited to the following: compilers, programming languages, runtimes, virtual machines, OS-dependent APIs, standards implementations, file formats and on and on. Anything involved with your program is probably coded somewhere ... and most of that code wasn't written by you.

Guess what happens when any of those layers breaks? The users and the customer blame the programmer. And they should, you know. The programmer made the choice to use the library* and he'll have to live with that choice as long as he's maintaining it. Then his replacement will have to live with his choice too, and his replacement and so on until the project gets stale and is used for french toast to make room for the new software.

So the choice is important. It's not always as easy as saying "oh, I'll just do it myself" or "forget that, it's already done over here I just have to tweak it a bit". It's also not as easy as saying "I better avoid Not Invented Here Syndrome at all costs!" either. Don't fool yourself into an antipattern of an antipattern. It's really all about risk, my friend. So add them up.

Now before you read any further, go read Joel Spolsky's opinion on Not Invented Here Syndrome. He makes a lot of great points and it doesn't make sense for me to regurgitate them. Don't worry I'll wait for you.

OK you're back. Let's continue ...

How risky is this library I'm considering using on my project? What attributes determine risk? That all depends on who you are. Here are a few considerations (feel free to add more in the comments):

--> is the library open source and if not, can I get the source if their business goes under?

--> does the library accurately follow an agreed on and published API, standard or specification? what deviations are in the library?

--> if it follows a standard, how many replacements are there? how do they stack up against this library?

--> what are the licensing terms of the library? or alternatively: how much will this library cost? and also: what are the distribution terms of this library? (huge consideration factors)

--> is the library extensible to my present needs? to my known future needs? to my unknown future needs?

--> what's the code quality? how many defects are logged against this library and what's the severity of those defects? can I fix the defects? can the library author fix them himself? what if I send him a patch, how quickly will it be incorporated?

--> is the individual or company maintaining this library easy to collaborate with or are they a pain the ass? do they embrace user feedback or dread it?

--> how many stable releases are there? how many partial or complete rewrites have happened? (hint: check the major version number)

--> is there a test suite against the library? was it made by another third party?

--> is the library written in a useful/usable language? can I technically even use the library?

--> what's the release schedule like? is the code rotting and in disrepair? or does it change too often? is there a stable maintenance branch for the long haul or will I be forced to feature upgrade to get bug fixes?

--> what other applications are using this library? what's their track record with it? what do users think of the end products that use the library?

--> is the library a leaky abstraction? if so, can I manage it? even in the long term? am I really sure about that?

--> is the library very well known or standard? can i leverage the programmers' knowledge of the library to speed development up and for maintenance later, rather than having new programmers learn all custom code when they are brought in?

--> and after all of those, finally: does the library perform well enough? can I improve performance if it doesn't perform well?

How to weigh each of these risks is up to you. You have to decide if using the library will actually save you time and effort or if it's just the cool thing to do. Using a third party library might seem like a time-saving decision but a poor decision can actually cost you time in the long long long run. It can also save you time, especially if the library is well known (Java, XML, Win32). Sometimes, like Joel says, a custom made in-house library is the way to go even though the problem has been 95% solved somewhere else. Ultimately it's a long term decision .... it's a very big commitment.

One last thing before I leave this topic: if you choose a library and use it you're not in a very good position to belly ache about its effectiveness afterwards. That's not to say you're not allowed to make suggestions but don't fault the library for your application's bad behaviour. You are responsible for work-arounds now. You made the bed and now you have to sleep in it. Maybe you'll make it more comfortably the next time around.

By the way, that includes web browsers too! They are just another layer, boys and girls. Use them properly .... but that's a rant for another day.

*let's not get into semantics on this point, his manager(s) may have chosen the underlying technology he uses. The choice is made by the project team.