Path: utzoo!mnetor!tmsoft!torsqnt!hybrid!scifi!bywater!uunet!motcid!murphyn
From: murphyn@motcid.UUCP (Neal P. Murphy)
Newsgroups: comp.software-eng
Subject: Re: Reusability considered harmful??(!!)
Keywords: Reusability, Division of Labor
Message-ID: <6416@bone13.UUCP>
Date: 4 Feb 91 01:22:33 GMT
References: <6108@stpstn.UUCP> <4842@cui.unige.ch>
Organization: Motorola Inc., Cellular Infrastructure Div., Arlington Heights, IL
Lines: 47

oscar@cui.unige.ch (Oscar Nierstrasz) writes:

>cox@stpstn.UUCP (Brad Cox) writes:

>>Could it be that we (reusability proponents) are shooting ourself in
>>the foot with the word, "reusability", just as the AI community did
>>themselves in with a term of their own choosing, "artificial
>>intelligence"?

>There is another problem, which is that "reusability" is only part
>(albeit an important one) of the story.  That is why I feel that it
>is better to emphasize "software components" and even "component-oriented
>software construction".  Even if you don't reuse a thing, it is important
>to organize applications in terms of interlocking components as this
>enhances robustness, maintainability and portability (though one could
>argue that these are all instances of "micro-reusability").

Components that are interlocked with each other, as you put it, are not likely
to be very re-usable, because it will take too much effort to remove
the locks from the components; of course, if the locks are placed *around*
the components, then, perhaps, you might have some re-usable code. Looking
at this issue from another point of view: one must first learn how to re-use
things before he can know how to make them re-usable in the first place.

...
>So, by talking about components rather than just reusability, we suggest
>that this is the correct way to think about software at various levels
>of abstraction (and that there is more to the story).  By talking about
>reusability, however, we only point to an abstract goal that is very
>hard to realize in practice.  We are still looking for the right view
>of software components that will actually give us the degree of
>reusability that we seek.

Perhaps you could consider components in terms of their reusability, since
it seems rather clear that 'components' in and of themselves do not
necessarily lead to reusable code, and that reusability is still a ...
nebulous concept. If your code modules are all interlocked, it is likely
to be easier to simply start from scratch, because it might not be worth
the effort needed to unlock and decipher that code. However, if you have
designed your modules (and sub-modules within them) with reusability in
mind, you will stand a greater change of reusing portions of the code
later, because you already minimized inter-dependencies in the code.

Code reuse save a lot of time and money, provided the components were
written with reuse in mind from the start.

NPN