Reuse Implies Coupling

From WikiContent

Revision as of 10:31, 24 July 2009 by Kmarquardt (Talk | contribs)
Jump to: navigation, search

Most of the Big Topics (with a capital b and t) in the discussion about software engineering and practices are about improving productivity and avoiding mistakes. Reuse has the potential to address both aspects. It can improve your productivity since you needn't write code that you reuse from elsewhere. And after code has been employed (reused) many times, it can safety be considered tested and proven more intense than your average piece of code.

It is no surprise that reuse, and all the debate on how to achieve it, is around for decades. Object oriented programming, components, SOA, parts of open source development, and model driven architecture all include a fair amount of support for reuse, at least in their claims.

At the same time, software reuse has hardly lived up to its promises. I think this has multiple causes:

  1. it is hard to write reusable code;
  2. it is hard to reuse code;
  3. reuse implies coupling.

The first topic has to do with interface design, negotiations with many customers, and marketing - and is covered by other aticles here that give sound advice how to design good interfaces.

The second has two aspects: it is mentally hart to want to reuse, and often technically hard to do so then. It works fine with operating systems, libraries, middleware. And we have enjoyed some components from open source projects. However, we often fail to reuse software from our colleagues or from unrelated projects within our company. Not only is it way more sexy to design something yourself, and you are surely way better at design than any of your peers. It also makes you depend on somebody else.

This dependency is the first aspect of coupling introduced by reuse. You are not the smith of your own luck any longer. You will be fine as long as the code you reuse is considered a commodity, something you really really don't want to do yourself. Otherwise, you will find good reasons why this code shouldn't be reused — like that you'd depend on something that you don't own, known, or maintain. Even if you'd want to reuse some code from elsewhere, the owner or manager of that code might not like your initiative. Providing code for reuse includes a more careful design, a more sophisticated change control, and spending effort in supporting the user — all leaving less time for other duties.

The other facette of coupling comes when you actually implement reuse within your company. All of a sudden, the provider and all of the reusers are coupled to each other. Each feature or change initiates debates about its relevance and priority, when it shall be introduced, and which interfaces will be affected. All the reusing projects struggle with each other and with the provider to have their expectation covered first.

Looking at reuse endeavors at different companies, these concerns are real. Successfully reused software typically brings a tremendous amount of management and overhead.

Alternatively, it requires a contemplative mindset of all involved parties. The other scenario to cope with reuse is to allow for deviations of the reused code for different projects. The projects evolve their own variant, reducing their coupling on the expenses of having less quality for free. This is not yet reuse, though. It becomes reuse when some developer is responible to integrate all variants every once in a while, and to evolve a baseline that becomes more stable over the months and years. With this mindset of sustainability over accountability, your company might be able to achieve the prerequisite for successful reuse: software that is considered a commodity.

By Klaus Marquardt

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools