Re: On Legacy Applications and Previous Work

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

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