|
'It's funny how common wisdom in the software industry is "reuse, don't rebuild", but if you look at projects that are actually successful and developers that are highly regarded, they all have a massive case of NIH syndrome.' Like all other absolute statements, it's wrong, just as the converse ("rebuild, don't reuse") is, and a balance is required. For context, I do a lot of XMPP work, which is all XML. In the languages I work in, I've gone through all the XMPP libraries that I know of, and found them wanting. I now use some layers I wrote myself directly around Expat. Why? Because nobody but nobody seems to be able to write an XML library that correctly handles namespaces! Which is death when working with XMPP. Yeah, if you hack hard enough you can get around the problem, but especially given the thinness of the usual XMPP libraries and what little they do, it doesn't take much to flip over to negative value. On the other hand, when I went to write a routine that takes a PNG file of arbitrary size and resizes it to be an avatar, I'd be a damn fool to yell "screw it!" and reimplement a PNG reader. So, it depends. Factors to consider include the long-term price you'll pay for a sub-optimal library, how close to core it is to what you are doing, whether or not you've ever implemented anything close enough to the library in question that you are really sure you can build something better (sometimes libraries suck because they suck, but sometimes they suck because they solve a hard problem and the "suckage" is actually the hardness of the problem poking out) as it is so easy to end up creating something worse, and, since I deal almost exclusively in open source now, whether you can take most of an existing library and actually bring it up to spec more easily than starting from scratch. One of my favorite maneuvers, not that I do it often, is to take some rather large library that does what I need but not terribly well, along with a lot of other stuff, and then tear it to shreds in the process of making it do what I want. A coworker of mine recently wanted to do zeroconf autodiscovery, so they started with dhcpcd and started tearing out everything except the use of the dhcp protocol, because it was easier than trying to start their own stuff from scratch. Worked great in less than an hour; I can't imagine what else they could have done in less time, even finding a conventional library, downloading it, and learning how to use it would have taken longer than that. |
I do use 3rd-party libraries. I'm a big fan of JQuery, for example - I can't use it in my day job because we literally count bytes when serving JavaScript, but I use it all the time for prototypes and personal projects. But I know that Resig is a top-notch coder, and more importantly, JQuery has had thousands of projects beat on it for a couple of years. If there're corner cases, they've been explored and uncovered, bug reports have been filed, and patches have been made.
Similarly, I use Apache/Lighttpd and MySQL and Django and PIL and BeautifulSoup (though I had some installation issues with PIL, so maybe that's not a great example of a well-tested, well-documented library). But these are pretty well-exercised projects with large userbases: other people have already done the dirty work of discovering all the bugs.
Makes me wonder why anyone would ever use new open source projects, which is essential to getting to the well-tested, well-exercised stage. I think it comes down to need: they'll reach for an imperfect library if the problem is so scary that they don't even want to approach it. So go work on hard problems, and you'll be popular. ;-)