johnson@m.cs.uiuc.edu (07/08/90)
This article is a response to one by cliffhanger@cup.portal.com (Cliff Heyer).
First, let me say that I agree with Cliff's main point, that
building software is research and not construction. There are
some people for whom building software is construction. They
keep building the same software over and over again. These
people are mostly in data processing shops. They are the people
how should be using 4th generation languages. Or, put another way
/However, these guys should be reusing software instead of rebuilding
/it.
to which Cliff replied:
>Try it sometime, it's not as easy as you think.
He then went on to say why software reuse will not happen.
I am a Smalltalk programmer. Almost by definition, this means
that I reuse software everyday. Sometimes I reuse it in small
chunks, like a sequence or a set. Sometimes I reuse it in large
chunks, like a drawing package. I'm an academic, so I can't tell
you how I beat my competitors to market and make lots of money,
though I've heard plenty of commericial people who use Smalltalk
say that, and I know that my students tend to build their research
systems a lot faster than other faculty expect.
As you might think, I take a dim view of arguments that reuse
is impossible. Cliff's argument about the date validation function
assumed that the routine was not flexible enough and could not be made
more flexible because source was not available. This just implies that
either software has to be flexible enough or it has to be extensible,
i.e. you have to be able to extend it when needed. I share Cliff's
view that no one software package is going to be flexible enough to
meet everybody's needs, so that means that reusable software has to be
extensible. This is certainly no surprise to an object-oriented programmer.
Actually, I have never reused software without source. I am not sure
that I could, or that I would want to. Unlike Brad Cox, I think that
a successful reusable components business will depend on source code.
Although it is theoretically possible to document classes well enough
that they can be extended without access to their source, it seems much
more likely that people will just sell the source and not improve their
documentation standards. As people have explained, really good documentation
is as hard as or harder to write than good code. Current documentation is
good enough most of the time, and when it isn't I can read the source.
I think that many people, including Cliff, do not quite understand what
we mean by "building software from reusable components". We do not mean
that every line of the program is reused. Although my goal in creating
a class library is to make it so flexible that it can be reused without
further programming, that is an impossible dream. Even well developed
class libraries, such as those for user interfaces, require programming
to use. There are quite a few Smalltalk applications that do not require
any new user interface classes, but can be built entirely from the standard
classes. However, more often than I'd like, I have to make a subclass of
View or of Controller. In one sense, I'm still reusing software, because
a subclass inherits a lot of code from its superclasses. However, I
have to create new classes and write code for them, and so it is not
as simple as "plugging objects together".
Even when I don't have to write any user interface classes, I have to
write application classes and hook my objects up to user interface objects.
Thus, I always have to write code. Getting the user interface "for free"
means that I save a lot of time that I can use for building another system.
The purpose of software reuse is not to eliminate programming but to
eliminate *unnecessary* programming. Although some of what we do
when we design new systems is creative, some of it is routine, simply
regurgitating algorithms and data structures that we have learned
in the past. Software reuse lets us stop regurgitating. In other
words, it will eliminate that part of building software that is
predictable and so emphasize the creative part that is not predictable.
In that sense, object-oriented programming is going to make the problem
that Cliff mentions worse. However, it will greatly decrease the amount
of time that it takes to build software. Managers still won't know how
much time it takes to build software, but they will know that it takes
less time than it used to.
Reducing the time it takes to build software by an order of magnitude
can have a very big impact on the way one develops software. Iteration
and rapid prototyping are preached by the Smalltalk community because
they *can* build prototypes rapidly. I think that the managerial
implications will be profound, but I don't think anybody understands
them yet.
There are lots of unsolved problems with OOP and software reuse.
Writing reusable software is very hard, it is just reusing it that
is easy. We need to figure out how to make a marketplace for
components, since that seems to be happening very slowly. We need
to figure how to manage OOP projects, how to test OOP systems, how
to document them, etc. Thus, I am not claiming that OOP will solve
all your problems, but I do claim that it will give you a big enough
advantage that everybody will be using it in the future.
I'll finish with a story. I met a fellow on an airplane to San Francisco
who was a consultant with belt-way bandits. He was a Smalltalk programmer,
and he would build the prototypes that the belt-way bandits would use
when they were trying to sell the military on their project. He said
that he would spend the morning talking to his customer and spend the
afternoon building a prototype. The next morning, he would show it to
the customer, find what they didn't like, and make another iteration.
Most customers were completely blown away the first time he returned
with an executable prototype, since they expected another question and
answer session, not a demo. I imagine he has lots of repeat customers.
Ralph Johnson -- University of Illinois at Urbana-Champaignmitchell@community-chest.uucp (George Mitchell) (07/09/90)
In article <39400113@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu wrote:
`....
`The purpose of software reuse is not to eliminate programming but to
`eliminate *unnecessary* programming. Although some of what we do
`when we design new systems is creative, some of it is routine, simply
`regurgitating algorithms and data structures that we have learned
`in the past. Software reuse lets us stop regurgitating. In other
`words, it will eliminate that part of building software that is
`predictable and so emphasize the creative part that is not predictable.
`In that sense, object-oriented programming is going to make the problem
`that Cliff mentions worse. However, it will greatly decrease the amount
`of time that it takes to build software. Managers still won't know how
`much time it takes to build software, but they will know that it takes
`less time than it used to.
This emphasis on programming and building reflects much of what I think is
wrong about the way we usually view reuse. The major cost of software is in
maintenance, not development. The major cost of development is not in coding.
To gain the greatest benefit from reuse, we need to have components that can
be incorporated without alteration, without unit test, and without subsequent
maintenance. What needs to be available in the component market place is not
only code, but test data, warranties, and life cycle support.
--
George Mitchell, MITRE, MS Z676, 7525 Colshire Dr, McLean, VA 22102
email: gmitchel@mitre.org [alt: mitchell@community-chest.mitre.org]
vmail: 703/883-6029 FAX: 703/883-5519jwg1@gte.com (James W. Gish) (07/10/90)
In article <112789@linus.mitre.org> mitchell@community-chest.uucp (George Mitchell) writes: > > This emphasis on programming and building reflects much of what I think is > wrong about the way we usually view reuse. The major cost of software is in > maintenance, not development. The major cost of development is not in coding. > To gain the greatest benefit from reuse, we need to have components that can > be incorporated without alteration, without unit test, and without subsequent > maintenance. What needs to be available in the component market place is not > only code, but test data, warranties, and life cycle support. This may be what we need, but with the possible exception of very general pieces of code, I don't think we're going to get very much of it. It is far too difficult as a designer/coder to envision how your code is going to be used in the future, either its context or the exact requirements imposed on it. When we write code, we usually do it with a particular context or application domain and framework (for example, error handling/reporting) in mind. However, when we go looking for code to use/reuse, unless the intended context and framework meet our requirements, we will have to adapt that code to our needs. We may want more or less functionality than the code provides, we may not be able to satisfy its requirements in one way or another. I have done a fair amount of programming in Eiffel over the past year or so. I like the language a lot. ISE, the suppliers of the Eiffel compiler, claim to provide a library of reusable classes. The folks at ISE have put a lot of work into the classes in an attempt to make them reusable. I've put a lot of hours into trying to use many of these classes. In many cases, in particular the graphics classes, it has been a difficult and time-consuming experience. Part of the problem is with the documentation, but even if the documentation were perfect, a fundamental problem exists: the designers had a particular model of computation, a particular style, a particular context, a particular application in mind when they put together these classes. Unfortunately, my model, my style, my context and specifically my use of these classes didn't exactly match what was provided. The question is, how do you overcome these differences? In some of the cases I found that changes in the language would have helped me make the adaptations necessary to the existing classes, even if I hadn't had the code - which Eiffel requires. However, no changes to the language/documentation could help me come to grips with some of the differences. In order to make use of these classes, I needed to make changes to the existing code. Failing that, I simply would have had to start from scratch (which, BTW, in retrospect would have saved me many painful hours). It's easy to say make it right, provide the test cases, documentation and everything I need to use it as is, but the reality is that none of us is omniscient enough to foresee how our code is going to be used, especially in the ever-changing world of computers and their expanding domains. So, for the foreseeable future I believe our best hope is in providing intelligent tools for assisting us in adapting code and associated artifacts including, for example, documentation and test cases, to new uses. -- Jim Gish (jgish@gte.com) Principal Investigator Software Reusability Project GTE Laboratories Inc.
mitchell@community-chest.uucp (George Mitchell) (07/11/90)
In article <JWG1.90Jul9174438@bunny.gte.com> jwg1@gte.com (James W. Gish) wrote: `In article <112789@linus.mitre.org> mitchell@community-chest.uucp (George Mitchell) writes: `> This emphasis on programming and building reflects much of what I think is `> wrong about the way we usually view reuse. [....] `It is far too difficult as a designer/coder to envision how your `code is going to be used in the future, either its context or the `exact requirements imposed on it. When we write code, we usually do `it with a particular context or application domain and framework (for `example, error handling/reporting) in mind.... ` `So, for the foreseeable future I believe our best hope is in `providing intelligent tools for assisting us in adapting code and `associated artifacts including, for example, documentation and test `cases, to new uses. This comment reflects what I feel is an improper emphasis on implementation. It is partly because of the pervasiveness of this mindset that the appraisal of the "foreseeable future" is probably quite correct. However, if we are able to look at reuse from the total life-cycle, it can be possible [in a domain ANALYSIS] to identify domain specific objects with standardized interfaces. It can also be possible to DESIGN objects that provide the minimum essential functionality which can be extended without object modification. In IMPLEMENTATION it can be possible to create code and documentation that will permit the object to be easily reused and maintained. In MAINTENANCE it can be possible to have a domain wide CM program and provide support to all users. Finally, in the user statement of REQUIREMENTS it can be possible to communicate the requirements for a new system (at least partially) in terms of the previously specified objects that will compose that system. -- George Mitchell, MITRE, MS Z676, 7525 Colshire Dr, McLean, VA 22102 email: gmitchel@mitre.org [alt: mitchell@community-chest.mitre.org] vmail: 703/883-6029 FAX: 703/883-5519
ejp@icd.ab.com (Ed Prochak) (07/11/90)
In article <JWG1.90Jul9174438@bunny.gte.com>, jwg1@gte.com (James W. Gish) writes: > In article <112789@linus.mitre.org> mitchell@community-chest.uucp (George Mitchell) writes: > > > > > This emphasis on programming and building reflects much of what I think is > > wrong about the way we usually view reuse. The major cost of software is in > > maintenance, not development. The major cost of development is not in coding. > > To gain the greatest benefit from reuse, we need to have components that can > > be incorporated without alteration, without unit test, and without subsequent > > maintenance. What needs to be available in the component market place is not > > only code, but test data, warranties, and life cycle support. > > This may be what we need, but with the possible exception of very > general pieces of code, I don't think we're going to get very much of > it. It is far too difficult as a designer/coder to envision how your > code is going to be used in the future, either its context or the > exact requirements imposed on it. When we write code, we usually do > it with a particular context or application domain and framework (for > example, error handling/reporting) in mind. However, when we go > looking for code to use/reuse, unless the intended context and > framework meet our requirements, we will have to adapt that code to > our needs. We may want more or less functionality than the code > provides, we may not be able to satisfy its requirements in one way or > another. > [experience with Eiffel deleted] > > It's easy to say make it right, provide the test cases, documentation > and everything I need to use it as is, but the reality is that none of > us is omniscient enough to foresee how our code is going to be used, > especially in the ever-changing world of computers and their expanding > domains. So, for the foreseeable future I believe our best hope is in > providing intelligent tools for assisting us in adapting code and > associated artifacts including, for example, documentation and test > cases, to new uses. > > -- > Jim Gish (jgish@gte.com) > Principal Investigator > Software Reusability Project > GTE Laboratories Inc. That is exactly why there will be different supliers of software components. Each supplier will conform to a standard interface, but the component from each supplier will have slightly different characteristics. You then pick the one that most closely matches you needs. The hardware analogy shows this: the designer picks -a memory chip from hitachi -a processor from motorola -a digital to analog converter from TI -LED's from HP -and so on... Whatever works use it! as my freshman Chemistry professor always used to say. To get all this to work in software requires: 1 documentation that reasonably describes the component (interface, performance, "power" requirements) 2 standard interfaces so replacing the component is possible with little or no change in the specific application code. Finally, let me say that the components catalog that has been described would contain components for every problem. We need to start small. And actually in some sense we have already started with components like: operating systems drivers and communications protocols standard libraries (e.g. stdio in C) The point being that no one is claiming to have the perfect components for all occasions. Hardware designers for embedded systems often have do deal with more than just digital circuitry. Even analog hardware has some standard compoments (op-amps, bridge rectifiers, power transisters,...) A friend, who is a hardware type, often described what he was doing as editing, whenever he was building a circuit.) So the hardware analogy is valid when we remember that hardware is more than just digital. (Pardon the inconvenience during our remodelling of the signature file) Edward J. Prochak (216)646-4663 I think. {cwjcc,pyramid,decvax,uunet}!ejp@icd.ab.com I think I am. Allen-Bradley Industrial Computer Div. Therefore, I AM! Highland Heights,OH 44143 I think? --- Moody Blues
paj@mrcu (Paul Johnson) (07/11/90)
In article <JWG1.90Jul9174438@bunny.gte.com> jwg1@gte.com (James W. Gish) writes: ...... [Quoted argument from mitchell@community-chest.uucp (George Mitchell) about components being re-used without alteration] >This may be what we need, but with the possible exception of very >general pieces of code, I don't think we're going to get very much of >it. It is far too difficult as a designer/coder to envision how your >code is going to be used in the future, either its context or the >exact requirements imposed on it..... >I have done a fair amount of programming in Eiffel over the past year >or so. I like the language a lot. ISE, the suppliers of the Eiffel >compiler, claim to provide a library of reusable classes. The folks >at ISE have put a lot of work into the classes in an attempt to make >them reusable. I've put a lot of hours into trying to use many of >these classes. In many cases, in particular the graphics classes, it >has been a difficult and time-consuming experience. Part of the >problem is with the documentation, but even if the documentation were >perfect, a fundamental problem exists: the designers had a particular >model of computation, a particular style, a particular context, a >particular application in mind when they put together these classes. >Unfortunately, my model, my style, my context and specifically my use >of these classes didn't exactly match what was provided. I am also an Eiffel programmer who likes the language (Note: I have no other connection with ISE) and I would like to argue with you about this. I agree with your comments on the ISE graphics classes: they seem to have been hacked together for the "GOOD" browser (which isn't: I use the Curses one). Extensions are difficult, partly because too much low level stuff for them is written in C (I find this worrying: it seems like any time Eiffel does something difficult and interesting, you find it implemented in C: perhaps this will be fixed in Eiffel 3.0. I see the need for SOME C to underlie the implementation, but Eiffel 2.2 seems to contain a great deal more than necessary). I disagree with your comments about re-use in general. It may be difficult for an author with a particular application in mind to envisage all possible uses for a proposed re-usable class, but I do not think it impossible to arrive at a reasonable subset. My own mental attitude when designing re-usable classes is to imagine that I had found the proposed class in a library and ask: what facilities would I expect it to have? IMNHO the emphasis for a re-usable class must be on the concepts it supports, not on the implementation or the currently envisaged application. When the need for a class or class framework within a project is identified, the design of that class or framework should become a separate project. Meyer writes of extracting and brushing up classes after an application is finished. I disagree, and I think that the Eiffel graphics library is an example of what happens when this approach is employed. None of this should be taken as Eiffel bashing, or even ISE bashing, and certainly not Meyer bashing. Eiffel is an excellent language and ISE and Dr. Meyer are to be complimented on it. Its just the approach to class design that I don't like, and I feel that some parts of the library reflect what I see as mistakes. Paul. NOTE: I am crossposting this to comp.lang.eiffel so as to give Dr. Meyer a chance to see it and reply. If you do follow up, please consider which group(s) should see your article. TNX. PJ. -- Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@uk.co.gec-mrc | Fax: +44 245 75244
cox@stpstn.UUCP (Brad Cox) (07/11/90)
In article <JWG1.90Jul9174438@bunny.gte.com> jwg1@gte.com (James W. Gish) writes: >In article <112789@linus.mitre.org> mitchell@community-chest.uucp (George Mitchell) writes: > >It's easy to say make it right, provide the test cases, documentation >and everything I need to use it as is, but the reality is that none of >us is omniscient enough to foresee how our code is going to be used, >especially in the ever-changing world of computers and their expanding >domains. So, for the foreseeable future I believe our best hope is in >providing intelligent tools for assisting us in adapting code and >associated artifacts including, for example, documentation and test >cases, to new uses. You've put your finger squarely on the difficulty of cleaning up our software act. But, like Fred Brooks in "No Silver Bullet", you are viewing our prison walls, the software crisis, as an immovable obstacle rather than an infinite force, an irresistable incentive to escape. So long as we avoid coming to terms with incentives for providing test cases, documentation, and "everything I need to use it as is", we'll be stuck in the software crisis, no matter how intelligent we make our code adaptation tools. Because code adapation tools don't come to terms with the real problem, bringing division of labor to bear on software. The solution, the "silver bullet" is so simple to state, but so difficult to apply. To wit, it is to change the *culture*, not the *technology*, for example by creating a marketplace where the *consumers* are empowered to reimburse those who do things right, rather than as today, for doing things *wrong*. An example of the wrong way is the cost+fixed fee system. An example of the right way is the U.S. Ordnance Bureau + Congress's determination to have guns with interchangeable parts, *nomatter the initial cost*, and nomatter the gunsmith's objections. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
jwg1@gte.com (James W. Gish) (07/12/90)
In article <112896@linus.mitre.org> mitchell@community-chest.uucp (George Mitchell) writes: > In article <JWG1.90Jul9174438@bunny.gte.com> jwg1@gte.com (James W. Gish) > (That's me) wrote: > `So, for the foreseeable future I believe our best hope is in > `providing intelligent tools for assisting us in adapting code and > `associated artifacts including, for example, documentation and test > `cases, to new uses. > > This comment reflects what I feel is an improper emphasis on > implementation. It is partly because of the pervasiveness of this > mindset that the appraisal of the "foreseeable future" is probably quite > correct. However, if we are able to look at reuse from the total > life-cycle, it can be possible [in a domain ANALYSIS] to identify domain > specific objects with standardized interfaces. It can also be possible > to DESIGN objects that provide the minimum essential functionality which > can be extended without object modification. In IMPLEMENTATION it can > be possible to create code and documentation that will permit the object > to be easily reused and maintained. In MAINTENANCE it can be possible > to have a domain wide CM program and provide support to all users. > Finally, in the user statement of REQUIREMENTS it can be possible to > communicate the requirements for a new system (at least partially) in > terms of the previously specified objects that will compose that system. > This would be a nice world to live in, but I don't think its terribly realistic. I think that this is a noble goal which we should continue to strive for, but I'm not convinced we will achieve it until we change some of our fundamental notions of software development. In particular, our idea of parts or components needs to be changed drastically of any kind of reasonable construction of parts to work like you want. Subroutines and parameters or even objects and methods as we know them today just DON'T cut it; they are just not easily composable. We desperately need some new ideas here. As far as domain analysis goes, the difficulty is that you don't just do a domain analysis and things are fine and stable from that point forward; domains evolve, and your standardized interfaces have to evolve along with the domains. Also, 'domains' are not something that you can easily define the boundaries of; I don't know of any that are completely self-contained. What ever you define your domain to be, it consists of many overlapping, co-dependent domains. The way to address this is to decide in what context, what model of computation, you want to use the results of your domain analysis. But context is related to the application(s) of interest in the domain. And here's the rub - new applications and technologies arise and, in effect, invalidate the requirements you made on your original domain analysis, further destabilizing your standard interfaces. But it is important to continue dreaming and striving... -- Jim Gish (jgish@gte.com) Principal Investigator Software Reusability Project GTE Laboratories Inc.
bertrand@eiffel.UUCP (Bertrand Meyer) (07/13/90)
From <558@argus.mrcu> by paj@mrcu (Paul Johnson): > > Meyer writes of extracting and brushing up > classes after an application is finished. What I wrote was, I hope, somewhat more nuance'. The observation to which Mr. Johnson refers is descriptive rather than prescriptive: many good reusable components have evolved from more specialized ones through a process of generalization. If you can write components that are reusable right from the start, then great. But an ``existence proof'' is required: you cannot be sure that a component is reusable until you have shown it to be at least usable. If the component's initial avatar was as an element of a specific but reasonably successful system, it has passed that first test - certainly not a sufficient condition, but a necessary one. The comment also has a more practical side. To develop good reusable components, it is certainly better to have as your official charter the development of reusable software components. Most people, however, work in a context where managerial concerns are more short-term; the decision makers want to see working programs more than they want to see high-quality reusable components. This is what (in published discussions of these topics) I have called the traditional ``project culture'', as opposed to the ``component culture'' fostered by object-oriented techniques. Since most people work in an environment where the project culture is the dominant one, the more modest approach to reusability - building up reusable components from specific ones, as opposed to more ambitious efforts having reusability as their avowed goal - may be the only practical one. I have seen it work quite well. I agree with Mr. Johnson that its success requires the designer to have a mental model of future component usage which goes beyond the original application. The only way to validate this model is to apply the components successfully to two or more widely different applications. -- -- Bertrand Meyer bertrand@eiffel.com
dwiggins@atsun.a-t.com (Don Dwiggins) (07/28/90)
In article <5351@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes:
The solution, the "silver bullet" is so simple to state, but so difficult
to apply. To wit, it is to change the *culture*, not the *technology*,
for example by creating a marketplace where the *consumers* are empowered
to reimburse those who do things right, rather than as today, for doing
things *wrong*. An example of the wrong way is the cost+fixed fee system.
An example of the right way is the U.S. Ordnance Bureau + Congress's
determination to have guns with interchangeable parts, *nomatter the
initial cost*, and nomatter the gunsmith's objections.
The motivation for interchangeable gun parts was pretty clear to the
consumers, e.g. the ability to make quick repairs in the field. What's the
consumer's motivation when the programs look the same to him/her, no matter
how they're built? Can we make a persuasive case that reusability leads to
faster/better/cheaper (especially when this case is in dispute among the
producers)?
--
Don Dwiggins "If you think training is expensive,
Ashton-Tate, Inc. try ignorance"
dwiggins@ashtate.a-t.com -- Derek Bok, Harvard U.duncan@dduck.ctt.bellcore.com (Scott Duncan) (07/30/90)
In article <DWIGGINS.90Jul27174047@atsun.a-t.com> dwiggins@atsun.a-t.com (Don Dwiggins) writes: >The motivation for interchangeable gun parts was pretty clear to the >consumers, e.g. the ability to make quick repairs in the field. What's the >consumer's motivation when the programs look the same to him/her, no matter >how they're built? Can we make a persuasive case that reusability leads to >faster/better/cheaper (especially when this case is in dispute among the >producers)? I'd say that the motivation for customers of software would be a bit different since it isn't likely they could repair software in the field. However, there is a great desire on the part of software consumers, I believe, for customiz- able (in the field) software. Hence, offering a user modules that can be "re- uysed" with one another in different combinations might be a worthwhile con- sumer-oriented approach to reuse. I think folks often conceive of "reuse" as having to do with uncompiled, un- linked, unpackaged source code. But the example of command shell languages suggests, with the proper model of input/output, reuse (recombination to achieve customization) is quite possible at an executable, rather than a source, level. Speaking only for myself, of course, I am... Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan) (Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ 08854) (908-699-3910 (w) 609-737-2945 (h))