Reuse Implies Coupling

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Current revision (21:26, 7 August 2009) (edit) (undo)
 
(10 intermediate revisions not shown.)
Line 1: Line 1:
-
Do not make your code depend on some file that is intended to change as the project progresses.
+
Most of the Big Topics (capital ''B'', capital ''T'') in the discussion of 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 safely be considered tested and proven more thoroughly than your average piece of code.
-
It is very convenient to have a global file that lists all error codes in the system. When starting the new component, you proudly add a handful: look, I am a part of this! Only to find you colleagues to mourn about the extra build time. How dare you change this file?
+
It is no surprise that reuse, and all the debate on how to achieve it, has been 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.
-
Couldn't you just do what everybody does:
+
At the same time, software reuse has hardly lived up to its promises. I think this has multiple causes:
-
* reuse some error codes that are already in there.
+
-
* when existing codes don't match the intended meaning, document their specific meaning in your component documentation.
+
-
The <code>error.h</code> file was intended to provide a great place to look for the meaning of codes. At the same time, it is a central component that is intended to change as the project proceeds. So it is your base, but it is quicksand.
+
# It is hard to write reusable code.
 +
# It is hard to reuse code.
 +
# Reuse implies coupling.
-
How to get out? Consider this:
+
The first cause has to do with interface design, negotiations with many customers, and marketing.
-
* real generic error messages (in the style of STL exceptions)
+
 
-
* a distinct <code>error.h</code> file per component
+
The second has two aspects: It takes mental effort to want to reuse; it takes technical effort to reuse. Reuse works fine with operating systems, libraries, and middleware, whether commercial or open source. We often fail, however, to reuse software from our colleagues or from unrelated projects within our company. Not only is it way more sexy to design something yourself, reuse would also make you depend on somebody else.
 +
 
 +
Which brings us to the third cause. Dependency means that you are no longer the smith of your own luck. 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 to not reuse &mdash; such as depending on something you don't own, know, maintain, or schedule. Even if you want to reuse some code from elsewhere, the owner or manager of that code might not support your initiative. And providing code for reuse necessitates a more careful design, more deliberate change control, and additional effort to support your users, all of which leaves less time for other duties.
 +
 
 +
The coupling issues are amplified when you implement reuse across your company. All of a sudden, the provider and all of the reusers are coupled to each other. And worse, even the reusers are indirectly coupled to one another. Each feature or change initiates debates about its relevance and priority, its schedule, and which interfaces will be affected. All the reusing projects struggle with each other and with the provider to have their expectation covered first. Successfully reused software typically brings a tremendous amount of management and overhead (as well as the success).
 +
 
 +
An alternative approach for coping with reuse is to allow for forking, with deviations of the reused code for different projects. The projects evolve their own variant, reducing their coupling at the expense of having less quality for free. After a while this ceases to be reuse. It becomes reuse when, every now and then, all the variants are reintegrated into an evolving 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 [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
 +
 
 +
 
 +
 
 +
Back to [[97 Things Every Programmer Should Know]] home page

Current revision

Most of the Big Topics (capital B, capital T) in the discussion of 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 safely be considered tested and proven more thoroughly than your average piece of code.

It is no surprise that reuse, and all the debate on how to achieve it, has been 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 cause has to do with interface design, negotiations with many customers, and marketing.

The second has two aspects: It takes mental effort to want to reuse; it takes technical effort to reuse. Reuse works fine with operating systems, libraries, and middleware, whether commercial or open source. We often fail, however, to reuse software from our colleagues or from unrelated projects within our company. Not only is it way more sexy to design something yourself, reuse would also make you depend on somebody else.

Which brings us to the third cause. Dependency means that you are no longer the smith of your own luck. 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 to not reuse — such as depending on something you don't own, know, maintain, or schedule. Even if you want to reuse some code from elsewhere, the owner or manager of that code might not support your initiative. And providing code for reuse necessitates a more careful design, more deliberate change control, and additional effort to support your users, all of which leaves less time for other duties.

The coupling issues are amplified when you implement reuse across your company. All of a sudden, the provider and all of the reusers are coupled to each other. And worse, even the reusers are indirectly coupled to one another. Each feature or change initiates debates about its relevance and priority, its schedule, and which interfaces will be affected. All the reusing projects struggle with each other and with the provider to have their expectation covered first. Successfully reused software typically brings a tremendous amount of management and overhead (as well as the success).

An alternative approach for coping with reuse is to allow for forking, with deviations of the reused code for different projects. The projects evolve their own variant, reducing their coupling at the expense of having less quality for free. After a while this ceases to be reuse. It becomes reuse when, every now and then, all the variants are reintegrated into an evolving 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