Software Reuse

Software Reuse

[VAXTSD::SCHILLING1@atc.alcoa.COM]

Reply-To: SCHILLING%ATC.ALCOA.COM@RELAY.CS.NET

This may seem incredibly naive to those who have long experience in 
the Defense contracting game, but it deserves saying anyway:

If the benefits of software reuse are real, then --
      - A product that makes significant reuse of software should be 
	ready sooner than one that represents all new code.
      - Saying than another way, a product that makes significant reuse
	of software could be started later in the system development
	cycle. 
      - The reliability of a product that makes significant reuse of
	software should be higher that an equivalent product that
	represents all new code.
      - Other quality characteristics of a product that makes 
	significant reuse of software should be much more predictable 
	than one that represents all new code.
      - The maintenance cost of the product that makes significant reuse 
	of software should be lower.
If all of the above is really true, then the customer should be willing
to pay MORE for a product that makes significant reuse of software than 
for one that represents all new code.  

Pete Schilling			CSNET:	SCHILLING@ATC.ALCOA.COM
Technical Specialist		PHONE:	412/337-2724
Process Control and 	   PAPER MAIL:	Aluminum Co. of America
   Computer Technology Divn.		Alcoa Center, PA  15069
Alcoa Laboratories			USA

Re: Software Reuse

[D. Schimsky]

As a "Government" manager of major software developments, let me offer that
most of comments I've seen here relative to "re-use" appear academic.   

1. No, I would NOT pay more for a product that takes advantage of re-use,
since virtually my entire concern is to LOWER the price of software
development.  There is no way, short of pushing my nose in it, that I will
believe a paper analysis showing me how much I will save tomorrow if only
I give you more today.

2. Short of absolute mandate (translate to "I order you to...") the detailed
methods employed in the development of software are made on a very local level
by the people first in line for the responsibilty.  These are the Project
Engineers, or Program Officers, or some equivalent title.  I believe I know
what their opinion is concerning re-use, but it would be interesting to hear
them speak.

3. By what magic do you expect an organization as large and diverse and,    
sometimes, divergent, to adopt a methodology that begs for standardization,
cooperation, flexibility and a non-parochial attitude, when you would do
well to find one, small, isolated group, anywhere, doing the same?

Re: Software Reuse

[munck]

I don't know if I've ever seem a more straightforward explanation of the
DoD's Software Crises than this:

> As a "Government" manager of major software developments, ... There
> is no way, short of pushing my nose in it, that I will believe a
> paper analysis showing me how much _I_ will save tomorrow if only I
> give you more today.

Remember that the _I_ (underlining mine) is really "the poor slob who'll
be maintaining this system years after I get a job in Industry." 
Remember too, that EVERYBODY'S project is too important (major) to take
the risk of being the first to use any new technique.

Of course, with FORTRAN, JOVIAL, CMS-2, and/or the Chinese Army approach
to programming, there's no risk.  We KNOW that it will be late, over
budget, and buggy.  No surprises, no risks.

                      -- Bob Munck, MITRE

Software Reuse

[Dennis Doubleday]

In article <4658@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes:
>An interesting analogy.  It says a lot about prevailing software culture:
>
>1. Available chips do not always meet requirements exactly.  For instance,
>a board might need 3 NAND gates, but the 7400 has 4.  EEs just ignore the
>extra gate, or tie its pins to something stable.  In a similar situation,
>software people fume and gnash their teeth over "wasted space".
>
I've seen this standardized circuits analogy to software packages a number
of times, and I don't really buy it.  Software people are attempting to
deal with a much larger and less well-defined problem domain than
hardware people.  Otherwise, we wouldn't even need software.  We could
just design hardware to handle every application.

>2. Running wires around boards loses some performance, relative to cramming
>everything onto a single chip.  All the techniques for modules, objects, etc,
>tend to slow things down.  Again, software types tear their hair out and
>vow to recode everything into one assembly language procedure.  

Performance is an important issue in many time-critical applications.  I
don't know anybody who wants to code everything in assembler.  I do know
people who are WILLING to code in assembler if it's the only way timing
constraints can be met.

>In short, I believe there are no technical problems or issues with reuse;
>it's the software culture that has to change.  At present, the prevailing
>attitude is that the densely-coded, highly-optimized, do-everything program
>is a sort of ideal to which everyone aspires.

I don't think you're up to date on what's happening, at least in the Ada
community.  I just completed a 13.5K source line Ada program, of which
7.5K source lines were contributed by reusable utility packages that
I got from the Ada repository (abstract string, stack, list, counted 
ordered set, and binary tree data types as well as packages for 
command line interface, lexical analysis of Ada, and parsing).




-- 
UUCP:	seismo!mimsy!dday                        Dennis Doubleday
CSNet:	dday@mimsy				 University of Maryland
ARPA:	dday@brillig.umd.edu			 College Park, MD 20742
Fan of: Chicago Cubs, Chicago Bears, OU Sooners	 (301) 454-6154

Software reuse

[P. Cnudde VH14 (8218)]

Hello,

First of all I want to say that the point of this mail is not
to start endless Ada vs C/C++ discussions, but to have an open
minded talk about Reuse and the influence of the language on reuse.

A lot of people talk about reuse but does anybody have experience
with a company wide reuse system. Not only different development
teams but also different locations should be supported. 

I see the following topics:
1. Language independent:
* Reuse database search methods
* Distribution of reusable components to the engineer who reuses
the component. (Source code or compiled version, function based or
library based)
* Can everybody in de company develop reusable modules or should only
one team make such functions
* is it usefull to reuse really small functions (<5 lines of code) 
or is the overhead to great. When is it usefull to think about reuse?
* What about the psychological problems (Not Invented Here)
* Who responsible for the reusable functions (the originator or the user)?
* How to avoid "Ariane-5" disasters? 

2. Language dependent.
* Language "Package-library" support. Is Ada here better ?
* Object Orientation, does it really help for reuse?
* Generics, (or templates) is it needed, or can we have a reuse
system without it?


PS. Does anybody in comp.lang.vhdl tried real reuse using VHDL.
(That's the language I am most interested in)

Regards,


-- 


   ____________          Peter Cnudde
   \          /          Alcatel Telecom
    \ ALCATEL/           Switching Systems Division 
     \ BELL /            Microelectronics Design Center
      \    /             
       \  /              F. Wellesplein 1, B-2018 Antwerp
        \/                                        BELGIUM
                         e-mail  : cnuddep@sh.bel.alcatel.be
                         Phone   : +32 3 240 82 18
                         Fax     : +32 3 240 99 47

Re: Software reuse

[Ted Dennison]

P. Cnudde VH14 (8218) wrote:
> First of all I want to say that the point of this mail is not
> to start endless Ada vs C/C++ discussions, but to have an open
> minded talk about Reuse and the influence of the language on reuse.
> 

Fat chance. 


Turhan:  "How will it end?"
Kosh:    "In fire."


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Software reuse

[Erik Jessen]

P. Cnudde VH14 (8218) wrote:
> 
> Hello,
> 
> First of all I want to say that the point of this mail is not
> to start endless Ada vs C/C++ discussions, but to have an open
> minded talk about Reuse and the influence of the language on reuse.
> 
> A lot of people talk about reuse but does anybody have experience
> with a company wide reuse system. Not only different development
> teams but also different locations should be supported.
> <snip>
> 
> PS. Does anybody in comp.lang.vhdl tried real reuse using VHDL.
> (That's the language I am most interested in)
> I'll post to all the original newsgroups once, then only post to comp.lang.vhdl.
For VHDL, from what I understand most companies have a structural problem: normally
the designers building the original blocks get positive reviews for getting chips out the 
door as fast as possible, not for spending time making modules that could be reused by other 
groups.

As a result, many companies are not seeing any value from 'reuse' because, while it is a 
good global thing, it isn't smart (from a personal point of view) for anyone in the company 
to work on it.

Change what gets people bonus money, and you'll see reuse happen a lot.

Some practical notes:

1) My company builds almost all of its chips as full-custom CMOS or BiCMOS; we do
	extensive reuse of layouts and schematics, in something that normally people
	don't think of when they say 'reuse'.

2) I think the only practical way to get reuse to happen is to have a separate modelling
	group that either develops reusable blocks from the ground up, or takes blocks
	built by other groups, and "packages" them with documentation, etc. to make
	them reusable.  You need people to have simple goals.  For designers, it should
	be "make it fast, make it right".  For library people, it should be "make it
	reusable".

3) At my previous employer, the DA group built up examples of how to run a complete
	methodology, using very small chips.  This was done using Make, SCCS and UNIX
	scripts.  Designers would either copy the methodology directly, or use it aas
	a template to develop their own.  I think VHDL code reuse will wind up somewhat
	like this.

Re: Software reuse

[Bob Stout]

Erik Jessen <Erik.Jessen@tus.ssi1.com> wrote:

>2) I think the only practical way to get reuse to happen is to have a >separate modellingg roup that either develops reusable blocks from the
>ground up, or takes blocks built by other groups, and "packages" them with
>documentation, etc. to make them reusable.  You need people to have simple
>goals.  For designers, it should be "make it fast, make it right".  For
>library people, it should be "make it reusable".

I heard a talk by Plauger once where he suggested there was a fundamental 
difference in mindset between the two types of programmers (this is true no 
matter what you call the two groups, applications vs. libraries, 
applications vs. systems, etc.) I tend to agree with this and believe it has 
a lot to do with an individual's most natural way of deconstructing a 
problem. The top-down people are apps programmers, the bottom-up people are 
library/systems programmers.

Re: Software reuse

[Stephen Baynes]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3651 bytes --]


P. Cnudde VH14 (8218) (cnuddep@sh.bel.alcatel.be) wrote:
: Hello,

: First of all I want to say that the point of this mail is not
: to start endless Ada vs C/C++ discussions, but to have an open
: minded talk about Reuse and the influence of the language on reuse.

: A lot of people talk about reuse but does anybody have experience
: with a company wide reuse system. Not only different development
: teams but also different locations should be supported. 

comp.software-eng might be a more suitable group for this question
particually for case tool support for reuse.
and perhaps also comp.sw.components. There are probably general OO
groups too. I have not added them to the groups because you have already 
crossposted to 5 groups which is more than enough.

: I see the following topics:
: 1. Language independent:
: * Reuse database search methods
: * Distribution of reusable components to the engineer who reuses
: the component. (Source code or compiled version, function based or
: library based)

Depends on what you are trying to reuse and how. May need all of them.

: * Can everybody in de company develop reusable modules or should only
: one team make such functions

Generally it is recomended that your applications developers should be
different from your reusable library developers because they have different
and conflicting goals.

: * is it usefull to reuse really small functions (<5 lines of code) 
: or is the overhead to great. When is it usefull to think about reuse?

You will normally need some as part of any reusable library to give a
sutable level of abstraction. There can also be small functions which are
usefully reused on their stand alone value [Eg strlen]

: * What about the psychological problems (Not Invented Here)

We have a "Proudly found elsewhere award"!

: * Who responsible for the reusable functions (the originator or the user)?

The library maintainer.

: * How to avoid "Ariane-5" disasters? 


You have missed out a lot of reuse by concentrating on code reuse.
Specifications, architectures, algorithms all can be reusable.

: 2. Language dependent.
: * Language "Package-library" support. Is Ada here better ?
: * Object Orientation, does it really help for reuse?

Objects are a convenient packaging mechanism, not a wonder cure. Most of the
problems with reusing objects are the same as those for any reasonably well
structured code.

: * Generics, (or templates) is it needed, or can we have a reuse
: system without it?

Again a convenient mechanism for delivering one type of reuse.

: PS. Does anybody in comp.lang.vhdl tried real reuse using VHDL.
: (That's the language I am most interested in)

: Regards,


: -- 

:    ____________          Peter Cnudde
:    \          /          Alcatel Telecom
:     \ ALCATEL/           Switching Systems Division 
:      \ BELL /            Microelectronics Design Center
:       \    /             
:        \  /              F. Wellesplein 1, B-2018 Antwerp
:         \/                                        BELGIUM
:                          e-mail  : cnuddep@sh.bel.alcatel.be
:                          Phone   : +32 3 240 82 18
:                          Fax     : +32 3 240 99 47

Did you kow that long signatures are disliked. Half a dozen lines
should be more than enough. The standard 'Rules for posting to Usenet' 
sujests 2 or 3 lines as enough.

--
Stephen Baynes                              baynes@ukpsshp1.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom
 Are you using ISO8859-1? Do you see � as copyright, � as division and � as 1/2?

Re: Software reuse

[Simon Davidmann]

Erik Jessen wrote:
> 
> P. Cnudde VH14 (8218) wrote:
> > <snip>
> > A lot of people talk about reuse but does anybody have experience
> > with a company wide reuse system. Not only different development
> > teams but also different locations should be supported.
> > <snip>
> >
> > PS. Does anybody in comp.lang.vhdl tried real reuse using VHDL. 
> Some practical notes:
> <snip>
> 2) I think the only practical way to get reuse to happen is to have a separate modelling
>         group that either develops reusable blocks from the ground up, or takes blocks
>         built by other groups, and "packages" them with documentation, etc. to make
>         them reusable.  You need people to have simple goals.  For designers, it should
>         be "make it fast, make it right".  For library people, it should be "make it
>         reusable".

In terms of hardware IC design I agree with this - and in fact have seen that for some specific technology 
areas groups of specialists with one focus will build blocks - specifically for reuse by many people - and 
will build a business from it. This is where Virtual Chips ( http://www.chips.com ) came from - originally 
from a consulting business - with a focus of building library components - but has evolved to focus on 
building synthesizable logic blocks (synthesizable bus interfaces for PCI, USB, AGP etc) for use by many 
people - and these come with the RTL design itself, the documentation (like a standard IC datasheet), 
synthesis scripts, and layout information - ie everything needed to get the design onto silicon.

I see a new industry evolving - focused on design reuse - individual companies may not be able to afford to 
build blocks for internal reuse (cost to design for reuse may be upto 5X regular cost) - it will need outside 
expert teams - who can spread the development cost amongs many customers. And this new industry will need new 
tools, new companies - and most importantly new relationships between supplier and customer - to license such 
technologies. 

The RAPID industry association ( http://www.rapid.org ) is being formed to address these issues.
Of course there are also all the issues related to the new EDA tools that will be needed for the reusable 
logic authors and the reusable logic consumers. These too need addressing.

Simon Davidmann
Virtual Chips Europe.
http://www.chips.com

Re: Software reuse

[Simon Davidmann]

Sorry that should be http://www.vchips.com

Simon.

Re: Software reuse

[Ari Lukumies]

Bob Stout wrote:
> 
> 
> I heard a talk by Plauger once where he suggested there was a fundamental
> difference in mindset between the two types of programmers (this is true no
> matter what you call the two groups, applications vs. libraries,
> applications vs. systems, etc.) I tend to agree with this and believe it has
> a lot to do with an individual's most natural way of deconstructing a
> problem. The top-down people are apps programmers, the bottom-up people are
> library/systems programmers.

This is a very interesting problem that I've been wondering about for a long 
time, since I've been working for years in (agreed, somewhat small) projects 
involving 10 to 30 programmers. It seems that many programmers do not "see" that 
some particular piece of code could be reused (when taken out of the current 
context with perhaps some modification) and yet some do (there are not as many 
of these people, though, it seems). It seems that this does not have anything to 
do with the educational level, position or experience. One thing I've recognized 
is that the people that write with reusable code in mind (even when they would 
be writing a program to do something very dedicated) often (but not all of 
them) play chess, too. So it might have something to do with pattern recognition 
or something like that.

About the top-down (apps programmers) vs. bottom-up (lib/sys programmers), I 
don't quite agree. I've seen many people start off with the general problem, 
breaking it down to smaller pieces and resulting to well reusable code. Also, 
I've seen many people starting with some small piece of code (reusable) and 
building on top of it, still retaining as much reusability as possible.

A way I often use is to write a program and then go through it to find common 
parts (algorithms, places that could be generalized etc) and then rewriting 
these. It's a little more work at first, but as time goes by, it'll cut down the 
need of rewriting tremendously. (But then again, I'm too lazy to rewrite 
anything so I try to make everything as general as possible :)

Finding out why these distinguished groups of people are distinguishable would 
result to better ways to divide the work between people (resource allocation). 
I've seen some projects where the writing of common parts were given to people 
who didn't have the "insight" to do it properly, or where some people able to 
write reused code where given tasks that did not need (or needed very little) 
generalization. This always slowed the projects down somewhat. As a 
designer/programmer/analyst and teacher of computing and programming, this 
problem is very close to my heart, not to mention that it might add something to 
our understanding about how a human mind works. I think there must be many 
people with many ideas about this out there. Am I correct?

Later,
 AriL
-- 
All my opinions are mine and mine alone.

Re: Software reuse

[Bob Stout]

Ari Lukumies <Ari.Lukumies@la.ccfo.carel.fi> wrote:

>> I heard a talk by Plauger once where he suggested there was a fundamental
>> difference in mindset between the two types of programmers (this is true >> no matter what you call the two groups, applications =
vs. libraries,
>> applications vs. systems, etc.) I tend to agree with this and believe it >> has a lot to do with an individual's most natural way=
 of deconstructing a
>> problem. The top-down people are apps programmers, the bottom-up people >> are library/systems programmers.

>This is a very interesting problem that I've been wondering about for a >long time, since I've been working for years in (agreed, s=
omewhat small)
>projects involving 10 to 30 programmers. It seems that many programmers do >not "see" that some particular piece of code could be r=
eused (when taken >out of the current context with perhaps some modification) and yet some do >(there are not as many of these peopl=
e, though, it seems). It seems that >this does not have anything to do with the educational level, position or >experience. One thin=
g I've recognized is that the people that write with >reusable code in mind (even when they would be writing a program to do >someth=
ing very dedicated) often (but not all of them) play chess, too. So >it might have something to do with pattern recognition or somet=
hing like >that.

Possibly, but I think not. I'm definitely a library programmer by nature, 
but I'm only a mediocre chess player. I am, however, *really* good at 
Scrabble. ;-) Seriously, though, the same principle would tend to apply. To 
be good at Scrabble, you have to be good at visualizing complex interlocking 
systems. (Hint: In Scrabble, the good players aren't always the ones who can 
come up with the big obscure words, but the ones who can drop 2 letters into 
a crowded board and get credit for 4-6 interlocking new words.)

>About the top-down (apps programmers) vs. bottom-up (lib/sys programmers), >I don't quite agree. I've seen many people start off wi=
th the general >problem, breaking it down to smaller pieces and resulting to well reusable >code.

Think back on the programmers you've known... The art/science of program 
design involves deconstruction of a problem. In all cases, you look at the 
big picture, then iterate until you have a defined set of components. Some 
people can begin designing a program with little more than a picture of the 
user interface. Most CASE tools work well with this mindset. These people 
are applications programmers.

Some people, though, can't really begin to think in terms of an overall 
design until they've deconstructed down to the component level. These people 
are library programmers. As you say, education, experience, etc. are 
secondary to mindset. It's also interesting that there's a really spiffy 
CASE tool called Utah that works backwards from others in that you design 
the data first before designing the screens around it. I would say that this 
is designed by and for this second class of programmers. Naturally, I think 
it's really a great tool.

>Also, I've seen many people starting with some small piece of code >(reusable) and building on top of it, still retaining as much r=
eusability >as possible.

Been there, done that! ;-) Had an idea of something really elementary that 
struck me as useful and built it. Afterwards, other people found it to be as 
useful as I had suspected.

>Finding out why these distinguished groups of people are distinguishable >would result to better ways to divide the work between pe=
ople (resource >allocation). I've seen some projects where the writing of common parts were >given to people who didn't have the "in=
sight" to do it properly, or where >some people able to write reused code where given tasks that did not need >(or needed very littl=
e) generalization. This always slowed the projects >down somewhat. As a designer/programmer/analyst and teacher of computing >and pr=
ogramming, this problem is very close to my heart, not to mention >that it might add something to our understanding about how a huma=
n mind >works. I think there must be many people with many ideas about this out >there. Am I correct?

One of the points of Plauger's talk seemd to be encouraging organizations 
that could afford to keep both type of programmers on staff, to identify 
them and treat them as equally valuable, but different, resources.

It's something that I've spent a lot of time observing and thinking about. 
As a software manager, I've been in positions to try to identify the skill 
sets and mindsets to do the best job in the least time. As a programmer, 
I've always wondered why I could write library code so easily that everyone 
seemed to like, yet I sweat bullets every time I have to work with some 
"visual" tool doing top-down CASE design. As you note, there doesn't seem to 
be a 50-50 split, either - good library programmers are hard to find. A 
causal look at things like gets() from the standard library tells you that a 
lot of people have written libraries without much thought!

As I final note, I'd add that in a discussion of this topic over in the 
FidoNet C_Echo recently, someone suggested, based on experience, that 
there's a built-in bias in the job and education market against the people 
who have an aptitude for library/system programming rather than application 
programming.

Re: Software reuse

[Steve Heller]

Bob Stout <bobstout@neosoft.com> wrote:

>As I final note, I'd add that in a discussion of this topic over in the 
>FidoNet C_Echo recently, someone suggested, based on experience, that 
>there's a built-in bias in the job and education market against the people 
>who have an aptitude for library/system programming rather than application 
>programming.
  I'm one of the latter types, and I agree that this specialty is not
generally regarded as highly in the job market as "Visual C++ GUI
application programmer". However, we're just as necessary as they are,
and considerably harder to find, so I have faith that the market will
adjust one of these days.
  As for myself, I'm now a full-time writer teaching C++ on the side,
so it doesn't affect me directly at the moment, but who knows when
I'll need a "real job" again?




Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller 

Re: Software reuse

[Stephen Baynes]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]


Bob Stout (bobstout@neosoft.com) wrote:
: Ari Lukumies <Ari.Lukumies@la.ccfo.carel.fi> wrote:

: Some people, though, can't really begin to think in terms of an overall 
: design until they've deconstructed down to the component level. These people 
: are library programmers. As you say, education, experience, etc. are 

If they start at or wait untill they reach the low level components before
looking for reuse then they are not much good. They should be aiming to reuse
whole subsystems, and in the extream to reuse the whole program.


--
Stephen Baynes                              baynes@ukpsshp1.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom
 Are you using ISO8859-1? Do you see � as copyright, � as division and � as 1/2?

Re: Software reuse

[Bob Stout]

baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) wrote:

>: Some people, though, can't really begin to think in terms of an overall 
>: design until they've deconstructed down to the component level. These
>: people are library programmers.

>If they start at or wait untill they reach the low level components before
>looking for reuse then they are not much good. They should be aiming to >reuse whole subsystems, and in the extream to reuse the whole program.

You're showing the mindset of an applications programmer. What you say is 
true if and only if the overall program is foremost in your mind. Library 
programmers, OTOH, deconstruct the program searching for solutions for the 
general case each step of the way. As each level is reached, the preceeding 
higher level is all but forgotten as a new set of problem domains emerge. 
When these become atomic, then the overall solution builds itself from the 
ground up.

Well designed subsystems aren't built out of application-specific building 
blocks, but out of well-designed components. What you're saying is 
equivalent to saying that to design a radio of reusable components, you 
design the IF subsystem without worrying about building it out of standard 
parts. This is obviously asinine! You build maintainable programs out of 
maintainable subsystems out of maintainable components.

The reason that most "reusable" components aren't reusable is due in large 
part to attitudes such as yours that view reusability within the tunnel 
vision of the task at hand. OTOH, some of the most reusable library 
functions start out life as general case solutions in search of specific 
sets of problems to solve.