Software reuse 
Author Message
 Software reuse

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

                         Phone   : +32 3 240 82 18
                         Fax     : +32 3 240 99 47



Fri, 29 Jan 1999 03:00:00 GMT  
 Software reuse


Quote:
> 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.          


                |  URL  - http://www.iag.net/~dennison         |



Sat, 30 Jan 1999 03:00:00 GMT  
 Software reuse


Quote:

> 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.



Sat, 30 Jan 1999 03:00:00 GMT  
 Software reuse

Quote:

>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.


Sat, 30 Jan 1999 03:00:00 GMT  
 Software reuse


: 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

:                          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.

--

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?



Sun, 31 Jan 1999 03:00:00 GMT  
 Software reuse

Quote:


> > <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



Sun, 31 Jan 1999 03:00:00 GMT  
 Software reuse

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

Simon.



Sun, 31 Jan 1999 03:00:00 GMT  
 Software reuse

Quote:

> 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.



Mon, 01 Feb 1999 03:00:00 GMT  
 Software reuse

Quote:

>> 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

Quote:
>> 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.)

Quote:
>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.

Quote:
>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.

Quote:
>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.



Mon, 01 Feb 1999 03:00:00 GMT  
 Software reuse

Quote:

>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



Tue, 02 Feb 1999 03:00:00 GMT  
 Software 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".

        Your conclusion is right if your assumption is right. And there I'm
not
so sure of. The designers goals are according to me (not in order
of importance) :

        - make it right
        - make it cheap
        - make it fast
        - make it power efficient
        - make it maintainable
        - make it reusable
        - make it ...  

ir. Jos De Laender
Alcatel Bell - VH14
Antwerp, Belgium



Fri, 05 Feb 1999 03:00:00 GMT  
 Software reuse

Quote:

>: 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.



Fri, 05 Feb 1999 03:00:00 GMT  
 Software reuse


: 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.

--

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?



Fri, 05 Feb 1999 03:00:00 GMT  
 Software reuse


Quote:
> <snip>

>         Your conclusion is right if your assumption is right. And there I'm
> not
> so sure of. The designers goals are according to me (not in order
> of importance) :

>         - make it right
>         - make it cheap
>         - make it fast
>         - make it power efficient
>         - make it maintainable
>         - make it reusable
>         - make it ...

> ir. Jos De Laender
> Alcatel Bell - VH14
> Antwerp, Belgium

When designing a chip at most companies, a designer puts re-use very far down on the list of things to  worry
about, even if it is a very important goal for the company as a whole.  In effect, the local optima (the
designer getting a bonus for getting the chip out the door) causes a global inefficiency (the company can't
reuse the design that was thrown together with no documentation).

This is just how people (and organizations) work.
Recognizing this, one must come up with a reward system that will cause the local optima to coincide with
the global optima.  Either

a) pay designers so that design for reuse is more important than getting it out the door fast
        (something i personnaly don't consider likely)

or

b) create a component-building group, who gets rewarded based on re-usability of their blocks, and
        reward designers for getting products out fast as possible.  This should generally cause
        designers to try and reuse as much as possible, because reuse is always faster than
        creating from scratch.

the problem isn't in which approach you use, the important thing is to recognize that people will do what
you reward them to do.  Designers are almost always rewarded the most, if the design comes out fast.
If a designer can get a chip out a month sooner and not have it reusable, or a designer can take the month and
make the design reusable, for which will Alcatel give a bigger reward?

Regards,
Erik Jessen



Fri, 12 Feb 1999 03:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. Troubling DoD software patent policy, and software reuse

2. Job-Vermont-Software Reuse Team - Software Engineer

3. Workshop on Software Reuse

4. Software Reuse conference CFP

5. OOP and software reuse

6. Matching Single-Sort Algebraic Specifications for Software Reuse

7. Software reuse and WEB.

8. National software reuse directory(NSRD)

9. Software Reuse

10. Software Reuse -- We Know More Than You Think

11. Software Reuse

12. Putting Software Reuse in the RFP

 

 
Powered by phpBB® Forum Software