I'm a library by default kind of guy, but it's always a series of trade-offs. For example: - how value adding is this functionality? - how well does the libra

I'm a library by default kind of guy, but it's always a series of trade-offs. For example: - how value adding is this functionality? - how well does the library meet my need? - is the library still under active development? - how stable is the library's API? (Building against an unstable API becomes a tedious waste of resources, fast.) - how good is the documentation? - is it popular/well-used? If so, this makes it easier to get help on Stackoverflow, or wherever, when I have a problem. There are times where we've started out with a library, but moved to a homegrown implementation, or vice versa. For example, we work with a lot of CSV input data. We started out with a library, because properly parsing CSVs is, well, not exacly tricky, but there are a pile of nuances and edge-cases you need to take account of. It was just much easier to use a library for this so that we could focus on adding business value elsewhere. Anyway, the size of the files we needed to work with grew, so we swapped the original library out for a different, faster, library. That worked well for a while, but then the size of the files we needed to work with grew again, and the library was too slow, so we swapped in our own faster CSV reader implementation for working with these large files. We still use the library for other CSVs because our implementation makes certain assumptions about the content of the files that don't hold for the smaller files we work with.