Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.software-eng
Subject: Re: Reusability considered harmful??(!!)
Keywords: Reusability, Division of Labor
Message-ID: <6248@stpstn.UUCP>
Date: 8 Feb 91 00:11:19 GMT
References: <6108@stpstn.UUCP> <87829@tut.cis.ohio-state.edu>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Organization: Stepstone
Lines: 99

In article <87829@tut.cis.ohio-state.edu> you write:
>Brad, in suggesting a replacement for the word "reusable" as
>applied to software components, you suggest that some opponents of the
>idea might argue:
>
>>"Reusability! Why 'reuse' software, when any fool knows it is cheaper
>>to throw used bits away and copy more from a master as needed."
>
>Seriously, now, have you really faced this sort of response to your
>ideas?  I knew we were having some trouble communicating with certain
>communities, but it never occurred to me that the problems might run
>so deep :-).

I threw that example out as one of many possible ways of misunderstanding,
not the only one. No one has made this particular argument, at least not to
my face. But I have sat thru a number of debates of the form "Reuse? Computers 
reuse code incessantly. Every operating system call, every pass through a 
loop, etc, etc".

I like "division of labor" because it focuses attention a change in
the *organization*, rather than a change in the *technology*.  It puts
the emphasis on specialization of labor (vertical), whereas reuse implies
a movement of code horizontally in a flat, homogeneous labor force.

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.

Reusable code results from a very deep change in an organization's
(and the individual programmer's) world view that I've tried to project
in the phrase 'Software Industrial Revolution'. To me, this phrase
means recognizing that people are different, programmers are different,
and the tools that they use are different too. 'Division of labor' tries
to capture the differences between the Ada philosophy (textual language,
tightly coupled), the Smalltalk philosophy (textual language, loosely coupled),
and ultra-high-level 'object-oriented languages' like Metaphor (coroutines,
lightweight tasks) and unix shell (heavyweight processes). Note that I'm
using object here in the broadest sense imaginable; encapsulation of state
and behavior with no requirement for inheritance.

Division of labor doesn't mean that programmers of these diverse types
operate independently of one another, as is required today given the
jihads separating adherents of the Ada (C++), Smalltalk (Objective-C), 
and Metaphor philosopies. With widespread adoption of division of labor,
technical means would arise that would make it possible for Ada or C++
devotees to specialize in building low-level components (gate- and
block-level objects) to be invoked (reused) by Smalltalk (i.e. Objective-C)
devotees in building higher-level chip-level objects (Software-ICs).

The division of labor notion recurses from there. Smalltalk or Objective-C
chip-level components could be used by end-users with no specialized 
programming skills at all if packaged as Metaphor-style card-level objects;
visual iconic objects that operate as coroutines, not subroutines.

Incidentally, I've been pushing this gate, block, chip, card, rack-level 
terminology for precisely the same reason that I'm pusing division of
labor. I've wondered why some programmers reject it as a controversial
statement of some kind of radical position, when I view it as unremarkable
common sense.

Puzzling. I've always regarded this terminology as only a way for reducing
the confusion when talking about matters that cross different levels of
integration. I don't view it as staking out some controversial new position,
but applying old and non-controversial terminology (from hardware engineering)
to highlight software architectural levels that most programmers take for
granted (i.e. the distinction of level between expressions, subroutines, 
instances, tasks, and processes).

>By the way, I applaud your recent emphasis (in a couple postings) on
>specification of external behavior, as an alternative to source code,
>as a way of explaining/understanding component behavior.  Maybe we
>could resurrect the discussion here (mostly flames) of a couple years
>ago when we suggested that software components should be sold as
>specification + object code, and that source code should remain
>hidden.  Talk about a hard sell...

By all means, do! 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?

By the way, a specification/testing language would be a *WONDERFUL* 
research topic for an energetic young graduate student. If there are
any takers, I'd be delighted to help. 
-- 

Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482