1. The underlying software landscape is still changing rapidly--20 years ago you were most likely programming for text-based interfaces, then you started programming for 16-bit Windows, then 32-bit Windows, then browser apps, and so on.  Imagine that you had written some of the most fantasically designed and reusable UI components for DOS text-based applications.  How useful are they for Windows apps or web apps?  Not at all.
   
   The problem isn't that the original designer designed the compoents wrong; rather, the rules had changed and the solution that worked in the past is no longer relevant.  Imagine you took someone who has only built igloos all her life and told her to build a house out of wood and brick.  Many of the solutions she used while building igloos
   
2. Things that look like they should be reusable often aren't.  My favorite example here are the oft-mentioned-but-never-quite-successfuly-implemented "shared business objects" that will be useable by all departments in a company.  Many times I've seen this attempted.  Depending how long you've been in the software industry, you might not be surprised when I say I've seen them fail an equal number of times.
   
   The main recurring problem I see here is that what's important about simple, central business concepts--an order, for example--varies wildly from department to department.  To a salesperson entering the order, it's all about the order lines, pricing and stock levels.  The shipping department is concerned about how many boxes will need to be packed, what size they are, how much they weight and where to ship them to.  Alternatively, the invoicing department couldn't care less about the shipping address.  The billing address, though, is of crucial importance.
   
   Yes, it's all one order, but its meaning massively changes while it moves through the process pipeline.
   
   The typical solution to this is to try to stuff everything that any department could possibly need to use into the object, making it huge, unwiedly and slow (oh! oh!  sounds like you're gonna start needing to use lazy load).  The problems, though, are just beginning: you implement a DeleteOrderLine() method, and it works great for sales reps who need to delete an order line during the order entry process when the customer says, "oh, wait, nix those three printer cables I just mentioned."
   
   All fine and good, but how will DeleteOrderLine() work when the package is returned by the shipping company and the warehouse has to delete the order line--because it turns out shipments to a certain foreign country are limited to 40" long since the last leg of the journey is flown in a Cessna and the package won't fit in the airplane?  I encountered this at my last job.  For this case, DeleteOrderLine() would have to refund the customer (since they had been invoiced already), and probably notify someone to send an apologetic email, and so on.
   
   Or how about an order line for a backordered part that, after serveral weeks, you realize has been discontinued?  This time you don't have to refund the customer (since he hasn't been invoiced), you'll have to notify the sales rep that they need to contact the customer and explain the situation (and options).  And we're just looking at a couple of scenarios for one method.

Am I arguing, then, that software reuse is impossible?  Absolutely not!!!  Certain pieces of software has achieved remarkable reusability, things like the C runtime library and the Java and .Net runtime libraries.  I've been using functions like sprintf() for 20 years now, in DOS, in Windows, UNIX, and back-end processes.  I'm pretty positive I'll be using it for at least a decade more; that's exceptional reuse in my book.

And that's the key to writing reusable software--keeping functionality very concise, and only targetting things that have reasonably broad appeal across many types of programs--some of the examples I've seen implemented successfully and reused often are date conversions between systems, logging functionality, and exception handling management.

Fortunately for us, though, much of the functionality like this has already been implemented in things like the .Net Framework runtime and the Microsoft Enterprise Library.  That means that there's not a ton of stuff out there that's reusable but hasn't been implemented already, so there's not a lot of new opportunities for us to write reusable code.  But that's good thing, since it means we immediately start reusing this code without having to write it in the first place.

Ben