Re: On Legacy Applications and Previous Work

baxter@austin.sar.slb.com (Ira Baxter)
Wed, 16 Mar 1994 00:50:05 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: baxter@austin.sar.slb.com (Ira Baxter)
Keywords: tools, bibliography
Organization: Schlumberger Laboratory for Computer Science
References: 94-03-034
Date: Wed, 16 Mar 1994 00:50:05 GMT

Paul Robinson writes about the lack to tools to support legacy code:
[heavily edited:]


    >1. Most programmers - my personal estimate is 90% - will spend 75% of
    > their time maintaining "legacy applications", e.g. the old programs
    > that are in use by companies that are the "crown jewels" of the
    > organization.
    >
    > - We need better tools, and ways to make maintenance - which is still
    > 70% or more of most people's work - easier to accomplish.
    >
    > - We need to increase the amount of code which is reused.
    > [lots of other suggestions]


Traditional SE wisdom is that 80% of software effort goes into maintenance.


But we currently do it very badly, partly because we have little
theory about it. You can find one version of first stab at that theory
in:


@article(Baxter92b:design-maintenance-systems-overview,
      title = "{Design Maintenance Systems}",
      author = "Ira D. Baxter",
      journal = "Communications of the ACM",
      year = 1992,
      month = apr,
      volume = 35,
      number = 4,
      pages = "73-89",
      annotation = {Suggests that Design Maintenance rather
than Code Maintenance should be focus. Shows how
formal (transformational) model of software
construction can be used to generate design histories
                                (essentially a rationale for derived program structure
                                  in terms of the program specifications),
and also implicitly defines types of formal
maintenance deltas, classes of changes that can be
made. Procedures for updating a captured design history,
given a specific maintenance delta are sketched.
A diagram in the back of the paper shows how a DMS
automates most of maintenance process for a simple
program. The diagram also shows how much additional
information is needed by a DMS to do this, and how
little of this information is available to the
maintainer, thus giving one good reason why
conventional maintenance is so hard.}
)


Surprisingly, this same theory suggests how to make reuse more
effective. Often, code isn't reusable because it needs to be changed
to embed it in a new context; reusers understandably don't want to
spend more effort to understand a reusable part than the coding time
it saves. Tools that can display and modify the design backing up
such a reusable part would be of great help.
--
[Ira] baxter@austin.sar.slb.com 1-512-331-3714
Schlumberger Austin Research
PO Box 200015, Austin, Texas, 78720, USA [mail]
8311 North 620, Austin, TX 78726, USA [plant]
--


Post a followup to this message

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