|
Most 10x coders deal with it by not using 3rd party libraries, except for ones that are very highly regarded and trusted. These tend to avoid most of the configuration headaches because everyone uses them, so the maintainers get lots of practice in making them easily installable. 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. Google and Microsoft both build all their own software. Mozilla completely reimplemented COM for Gecko. John Resig just got criticized recently because TestSwarm duplicates a lot of the functionality of Selenium Grid. Linus Torvalds wrote his own OS instead of hacking MINIX, and then wrote his own VCS rather than use Subversion or CVS. Chuck Moore wrote everything himself, down to the hardware, which he designed with CAD software he wrote himself in Forth, a language he wrote himself. If you look at it by numbers, this makes perfect sense. The average library is, by definition, average, so a coder who is way above average can undoubtedly write something better given enough attention to the problem. Plus, many of these super-coders got their reputation by writing lots of code in the first place, which you don't do if you just reuse third-party libraries. Unfortunately, everyone thinks they're above average, which is why we get such a profusion of libraries in the first place. ;-) |
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.