Reading an article just now, something sparked off a thought process. I remember talking my manager years ago about things in general and he came out with something like 'object technology never lived up to its promise of reuse'.
Apart from the fact that I disagree that object technology has anything to do with the reuse argument, his comments about reuse were (and still are) a sore point with some folk. Reuse has long since been a holy grail of software development. We long to be able to plug together components like those clever electronics engineering types do, so that we can drastically reduce the time it takes to build software.
To attempt to achieve reuse take time and investment, something most projects cannot afford. On every project I have worked, there was a targeted deliverable and on those where the IT staff lost sight of this, the results were disastrous. But even if the project was will to spend the extra time and money investing in an attempt to build reusable parts, what is the return on investment? I have no doubt it can be made to work - but when I have seen this, there has always been a price to pay - code is very often in worse shape after refactoring changes required to make it work in a second context.
So, even if we could (i.e. we have the funding and the commitment from the project) should we do it? There are only two scenarios here I can think of -
1. We build something to fulfill an expected need and try to design for all occasions
2. We build something that fulfills the needs of a real product and try to adapt it to other solutions
The problems with 1 are that we're in an endless assumption mode, we don't know when we're done because we have no sound business reason for building something and its impossible to foresee what real projects actually will need. While I favor item two because its grounded on reality and emerging needs, it's still often impossible to reuse that part on another project. The more coarse grained the component the hard it will be to reuse it - because business rules are always different across projects.
This brings me to the next point I believe that level of abstraction is key to reuse. If we build some software to manipulate lists, it is much more likely that we can reuse it than if we build a class to calculate commission for a salesman. Why should this be? There are basic building blocks in life that can be use no matter what. Bricks and mortar and other building materials can be used to build a large array of different structures, but a house or a kitchen cannot be used to build a shopping mall. The closer to a business domain software gets, the more specific to that particular solution the code becomes, because most people in business actually want to do things differently to their competitors - in the belief that they can gain advantage by doing so.
Reuse takes many forms. Software especially libraries and fine grained (typically technology oriented) APIs, tooling and platforms and skills. The single most import item from which reuse can be gained, is the brain, knowledge and learning should be foremost and everything else will fall into place.