Why is software reuse so hard? My initial response to this was thinking about the human nature of pride and protectionism. Creators have a natural tendency to want to keep their creations owned by themselves. “Intellectual Property” is such a rush right now, with people screaming, “I thought of that first! You aren’t allowed to copy it, because it’s such a good idea!” The whole idea of proprietary software hinges on not sharing on a global scale.

The book describes more about software reuse within a company; namely, Software Product Lines. They describe how proactive reuse is difficult (because it’s Big Design Up Front) and typically ignored. Reactive reuse, on the other hand, is a basic point for refactoring and the whole DRY principle: if something’s repeated, separate the commonalities to reduce repetition. At some level, it’s a question of randomness and compressibility: Software is incompressible if it has no repetitions, and refactoring is a form of compression.

The book also describes how both protectionism and ignorance of surroundings lead company divisions away from reuse. I really like the notion of a Champion leading a company to software reuse. Just like anything else in a corporate environment, the software development is led by the culture, and the culture needs a figurehead to follow (sounds like “K&R style is good! Software reuse is good! Learn many languages and frameworks and always use what’s most appropriate!”).

One thing the book doesn’t cover, and probably rightly so, is the open source community approach. This environment has very different attributes:

  • Many large-scale projects (linux kernel) have a Benevolent Dictator For Life as a champion
  • Software reuse is common for niche libraries because time is the most expensive resource for a spare-time developer (the TRIANGLE package is a very small open-source Delaunay triangulation package, and it is referenced quite often).
  • Similar libraries tend to be written by developers who know about the others, because the information is available on the Internet (someone releasing their own module to the public would likely have evaluated other available modules that are similar prior to even starting work).
  • Organizations like CPAN heavily promote module sharing
  • Protectionism is not prevalent by nature of the F/OSS mentality.

It would take quite a bit more research to examine how architecture and software reuse function in various open-source environments.

Advertisements