🚀 go-pugleaf

>(William Thomas Wolfe, 2847 ) writes:
>
>      This assumes that everyone can unilaterally decide to produce 
>      components which are large enough to justify reuse, which is
>      contradictory to the assumed software engineering methodology.   
>		       ^^^

Generally, reusable components must be more reliable than those intended
to be used once - more effort must be put into making them *correct* and
creating *robust* versions (two different things!).  The additional resources
to do this should probably be allocated centrally, on a priority basis, by
someone with organization-wide responsibility.

>      In order to reduce the chaos which would result if everybody 
>      could create components on their own, each required component
>						 ^^^^^^^^

Re-use is an incremental thing.  Casual re-use implies that a piece has
been *found* that is useful.  Organized re-use implies that a piece has
been designed to be reusable.  Both kinds require a central registry for
reusable or potentially reusable code.  A set of simple metrics like 'how many
projects has this been used in' is probably a good starting point for
determining 'how' reusable something is.  There is also the issue of whether
a class/library designer should be required to support a class for the use of
others, or whether that responsibility should pass to the central registry.

>      is identified in the detailed design phase and the librarian
>		       ^^^
>      provides information regarding the match (or lack thereof)
>      between the component requirements and the component supply.

Don't forget that the librarian should be looking *first* for appropriate
libraries outside the organization, presumably produced and maintained by
those whose primary business is producing and maintaining *that* library.
To do otherwise is to dilute effort into areas others have already covered
adequately, and diminish the value-added of one's own product.  The same
organization-wide position should be responsible for purchasing libraries
from outside, or commissioning their development into reusable code inside.

>The highlighted words imply a particular scenario for the library and the
>software development environment that it's imbedded in.  I can envision a
>number of reasonable organizational and procedural arrangements that would
>lead to different degrees of "coupling" between the producers, librarian,
>and consumers.  Could you elucidate your assumptions in the above statement?

Since I've butted in on this :-), I should at least explain my own assumptions:

1. Central registry and resources for reusable software are crucial.
   Word of mouth is not adequate publicity, and casual change/fix requests
   are not adequate support for reusable code.

2. If reusable code emerges from a project not specifically oriented towards
   producing it, that is a nice coincidence, but if code is to be supported
   across more than one project that must be a concious decision - other
   decisions, such as to buy that particular functionality for later projects,
   are certainly possible and must be considered carefully.  A lot of resources
   can be consumed making code correct and robust.  Someone must be made
   responsible for supporting the code in its new, general, role, and resources
   must be available for that - at first, very substantial resources, as the
   culture of re-use has to be built and encouraged.

3. 'Correct' code responds correctly to correct input.  'Robust' code responds
   predictably to incorrect input.  'Robust' versions of code can be derived
   from 'correct' versions, as they retain the same interface and only add 
   some error-checks.  The two versions can then be used interchangeably as
   the situation demands.  Usually both must be available for real reusability.

4. In larger organizations (more than 10 people!) a microcosm of the larger
   set of roles can be mirrored for projects or groups of projects.  Someone
   may be responsible for searching the organizational code resources for
   items useful in the current project.  Someone else may be responsible for
   specializing these.  The central registry may decide if the specializations,
   or any new code generated, should be included in the organizational resources.
   This may sound bureacratic but it's the way other forms of information 
   resources are re-used in organizations (legalese, business letters,
   insurance policies, etc.)

>Having made this request, I guess it's only fair to expose the model that
>I'm assuming.  I'm thinking of a software development organization that
>produces "products" (where the consumers may be outside customers or
>internal users), and has several projects going on at once (some of which
>may be related).  Rather than having a separate group of "component
>producers", components would be produced as spinoffs of normal development
>activity.  This would, of course, involve some overhead (from the point of
>view of the project manager) to either plan or retrofit the desired
>qualities into the component.  I'm not advocating this as the only way to
>go, but it seems like a reasonable initial goal for a multi-project
>organization.

The danger with this should be clear by now - the project manager is not
being encouraged or rewarded to design good reusable code - quite the 
opposite.  His/her project deadlines and costs are being impacted by an
activity that he/she has no resources or incentive to support.  Planning and
retrofitting are both time-consuming activities, and when you consider that
the interface to the basic code facilities of the project are the first
bottleneck any project runs into... 

A useful alternative would be to identify certain key projects as likely to
produce large portions of reusable code.  These should not be projects that
are business-critical or have tight deadlines.  Ideally, they should almost
be 'optional' or 'CEO pet projects' with low consequences for failure.  A
group of people ready to risk some prestige for the sake of getting involved
with a new technology, perhaps a group with something to prove or make up for,
might make the best team.  It should be emphasized from the beginning that
the degree to which their work is re-used will be a crucial factor in
evaluating the project - perhaps more so than the final result.  All of this
should be visible to the team from the beginning.  This group may later become
your corporate component library.

Without such projects available, another possibility would be to create a 
group to work with project managers and designers in the early stages of 
*all* projects.  Such a group would need expertise in every application area
that the company works in, because they would need to evaluate the potential
for re-use of every piece of code produced by every project.  With their help,
the project manager should be able to define interfaces early enough to stay
on deadline.  For co-operating, some incentive such as increased administrative
resources (for those extra phone calls!), longer deadlines (if a project can't
come in two weeks later to serve a major long-term goal, your company is
already in trouble), conference/training support, or even some fun money
(an interesting excursion at the organization's expense).  In any case, it
is necessary to back up the corporation's interest in this long-term goal
with some visible support.  The more visible the better.

>Unfortunately, I haven't received Johnson's message, and I'd rather not
>comment on an excerpt out of context, but I will say that having more than
>one implementation for a given spec can be useful for more than performance
>reasons (portability to radically different environments, for example).

Essentially the 'correct' vs. 'robust' distinction is two implementations on
what is really the same spec (most specs don't include error recovery).
I agree that the inheritance matrix is an implementation mechanism, and if
I could build a separate one for the users (of my library) to see, I would.
The functional relationships may not be identical to the implementation matrix.

>Don Dwiggins				"Solvitur Ambulando"
>Ashton-Tate, Inc.

    Craig Hubley			-------------------------------------
    Craig Hubley & Associates		"Lead, follow, or get out of the way"
    craig@gpu.utcs.utoronto.ca		-------------------------------------
    craig@gpu.utcs.toronto.edu    mnetor!utgpu!craig@uunet.UU.NET
    {allegra,bnr-vpa,decvax,mnetor!utcsri}!utgpu!craig    craig@utorgpu.bitnet

-- 
    Craig Hubley			-------------------------------------
    Craig Hubley & Associates		"Lead, follow, or get out of the way"
    craig@gpu.utcs.utoronto.ca		-------------------------------------
    craig@gpu.utcs.toronto.edu    mnetor!utgpu!craig@uunet.UU.NET