Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!elroy.jpl.nasa.gov!decwrl!infopiz!athertn!hemlock!mcgregor
From: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Newsgroups: comp.software-eng
Subject: Re: Reusability considered harmful??(!!)
Keywords: Reusability, Division of Labor
Message-ID: <34402@athertn.Atherton.COM>
Date: 8 Feb 91 22:22:39 GMT
References: <6248@stpstn.UUCP> <6108@stpstn.UUCP> <87829@tut.cis.ohio-state.edu>
Sender: news@athertn.Atherton.COM
Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Organization: Atherton Technology -- Sunnyvale, CA
Lines: 66

In article <6248@stpstn.UUCP>, cox@stpstn.UUCP (Brad Cox) writes:

> Notice how easy it is for an organization to superficially buy into the 
> idea of reusing code without putting into place the infrastructure required
> to make it successful. For example, notice how difficult it is to convince
> managers (and programmers) that reusing code effectively requires a stable
> dedicated group responsible for building, testing, documenting, and
> supporting this code, without distraction from other goals (i.e. building
> product) 'Reuse' is easy to buy into at the lip service level because it 
> does not impinge on ingrained value systems. Reusable code does not happen 
> as a side effect of something else.

I think that this is because most software managers and engineers have
some past experience.  They've learned some things that worked for them
and some that didn't.  Those who weren't able to adapt to today's way
of doing things washed out of the business in frustration. It is hard
to support a new way of doing things that might invalidate your past
experience and reduce your mature judgements to the same level as
a novice.  This is threatening, and so resisted. That is why it
is difficult to change the way people do programming from rolling
their own, to leveraging other people's code.  It raises a bunch
of uncomfortable questions: Will I enjoy doing that as much as I like
what I am doing now?  Will I be as good as it as I am now?  Will
I be just as valuable (irreplaceable, high salaried) as I am now?
Will I make as good predictions on how long development will take?
Will I be as quick to spot misdesigns and misimplementations?  Will
I recognize the quick short cuts that are reasonable?

> ... I've stirred this pot hard enough and long enough
> during the last several years to become convinced that there is no
> technical obstacle to a specification/testing language as outlined
> in my IEEE paper. The obstacles are not technical, but cultural. If
> we can't get management to fund dedicated components groups (or 
> equivalently, to buy components from external components groups like 
> Stepstone), how will we ever get them to fund these groups to also 
> build external specifications for the components and gauge their 
> compliance to specification?

Of course, maybe this question is asked wrong.  Maybe you shouldn't 
get experienced software engineers and managers to embrace this kind
of change that undermines their own experience.  Maybe instead you should
look at how to convince non-software managers to stop turning to their 
MIS department to do the work, and rather do it themselves--saving all
the communication time and confusion. Nondevelopers have nothing to lose
since they don't already start with an experience base. They might like
the very different work inherent in the new approach, which might not
suit professional programmers at all.  In some sense, this is what happened
with 4GLs.  Most of the early 4GL adopters weren't long experienced
COBOL coders--it was often end users and new programmers.  Many
end users write very sophisticated Lotus 1-2-3 Macros, but never consider
themselves programmers,  but very few C coders have switched to write most
of their code in 1-2-3. At  the same time though fewer end users are
waiting for MIS groups to write programs for them that they can work 
out themselves in 1-2-3.

It may need to be the same for adoption of component based programming:
It may be the end users who don't have time to wait for an official
coding resource who turn to purchasing and using components.  If so,
this suggests substantial changes to user interfaces, training, etc.
to make component selection and configuration attractive to such 
inexperienced developers.


Scott McGregor
Atherton Technology
mcgregor@atherton.com