Re: On Legacy Applications and Previous Work

bill@amber.csd.harris.com (Bill Leonard)
Fri, 25 Mar 1994 22:19:13 GMT

          From comp.compilers

Related articles
On Legacy Applications and Previous Work PAUL@TDR.COM (Paul Robinson) (1994-03-06)
Re: On Legacy Applications and Previous Work donawa@bnr.ca (chris (c.d.) donawa) (1994-03-21)
Re: On Legacy Applications and Previous Work bill@amber.csd.harris.com (1994-03-14)
Re: On Legacy Applications and Previous Work baxter@austin.sar.slb.com (1994-03-16)
Re: On Legacy Applications and Previous Work steve@cegelecproj.co.uk (1994-03-22)
Re: On Legacy Applications and Previous Work bart@cs.uoregon.edu (1994-03-23)
Re: On Legacy Applications and Previous Work pardo@cs.washington.edu (1994-03-24)
Re: On Legacy Applications and Previous Work bill@amber.csd.harris.com (1994-03-25)
Re: On Legacy Applications and Previous Work mboucher@silver.sdsmt.edu (1994-03-29)
Re: On Legacy Applications and Previous Work bill@amber.csd.harris.com (1994-04-04)
| List of all articles for this month |

Newsgroups: comp.compilers
From: bill@amber.csd.harris.com (Bill Leonard)
Keywords: tools, design
Organization: Harris CSD, Ft. Lauderdale, FL
References: 94-03-034 94-03-107
Date: Fri, 25 Mar 1994 22:19:13 GMT

Bill Leonard <bill@travis.csd.harris.com> wrote:
[...]
> Reusing large pieces of code is better. But writing reusable software
> that does something complicated enough to justify reuse is hard, real hard
> -- and time-consuming. Suppose you go to your manager and say, "I can
> have it done in 3 months, or a year if you'll let me make it reusable."
> I'll give you one guess which way the manager is likely to vote.


bart@cs.uoregon.edu (Barton Christopher Massey) writes:
> No, what you want to be able to do is go to your manager and say "I can
> have it done really well in 3 months, or we can buy Frobozzco's reusable
> component and I can get it running in three weeks." Unfortunately, this
> raises questions about programming languages and translators that we don't
> quite know how to answer yet.


That's okay for components that represent a very generic type of facility,
like a sparse matrix. But there is also a lot of potential for software
reuse on a somewhat smaller scale: reusing software within a single
organization or company. That is, reusing software that is a bit more
specialized to that company's field, but which nevertheless is useful in
more than one application.


That's the part that's hard to get into a reusable state to begin with,
because there is no "vendor" of the reusable component, only (potential)
consumers, none of which want to be the one to bear the cost of
development on the *promise* of reuse.


In some organizations, the accounting of that development cost is also a
problem. For instance, suppose you're working on a government contract,
similar to contracts you've worked on before and will likely work on
again. You see a potential for a reusable component, but it is going to
take additional effort to make it reusable. You will find it very
difficult to charge the government for that, and then use the software on
other government programs.


--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bill@ssd.csd.harris.com
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.