This is my reply to an article on TheServerside.com on code reuse.
My opinion, founded on about 10 years of business-side and 5 or so of casual programming is this: If you can find code that exactly fits your requirements, great, use it. But this is rarely the case. And at the very least, you're certain to find some bugs or, in a successful product, you outgrow it if it doesn't add additional features you require.
Thus, the sad fact is, rarely can code be reused, and this applies not only to libraries but to products themselves.
Luckily, there are several recent developments in software development that increase code reuse. One is that there are many fine free/open-source software (FOSS) projects you're free to modify to better meet your in-house requirements. In addition, people administrating these projects often have people who listen to requests and incorporate solicited changes back into their projects. Secondly, better source control management and build tools make it relatively painless to rely on external libraries, developed in-house or not, whereas before it may have been actually less work to copy & paste in some algorithm instead.
I've found dealing with code reuse issues in-house more difficult than working with (FOSS) or other vendors. For instance, if a series of classes seems appropriate to reuse for my project, but may require repackaging or other slight changes, not only do I need to approach developers, but often their project managers and come up with some compelling reason to touch their code. And so if "no" looms as a potential risk, I go ahead and copy & paste.
Things can get even worse if your team is into "code ownership": The more people's permission you need to touch something, the more likely I'll copy & paste.