Conference turris::languages

    
       "When the cost of maintaining it exceeds the cost of development."
    
       "As soon as possible."
    
    
    					-mjg
    
    (trick answers, if the system is "large" (large enough to have
    unobvious bugs) and/or requires major functional enhancements on a
    regular basis, the two are equivalent.)
    
       If nobody uses it, never!
    
       If it works, don't fix it.
    
       "It's probably cheaper to not write the system and hire teenagers to
    do the filing in the long run anyways."
    
    					-mjg
    

    ALL programs shold be rewritten every so often.  There a couple of
    reasons for this.
    
    1. Programs deteriorate unrer maintainance.  New 'features' are added
    while the old baggage is not discarded.  Maintainers with different
    programming styles make a mess out of the original program structure. 
    At some point the program becomes so unmaintainable that it should be
    thrown away.  Most people hang on too long.  As I noted earlier, MACRO
    programs deteriorate faster than most.  
    
    2. Technology changes and the assumptions made when the program was
    originally written are no longer true.  The best example is that larger
    memories make algorithms that use large data structure possible when
    previously they were not (example DECwindows, which would not have
    worked on the original VAX/780).  Other recent technology changes are
    the move to personal computers which is making big changes to the user
    interface and the speed up of processors with respect to IO.
    
    The average program can be expected to have a life of 5 to 10 years,
    but there is room for great variations in this.  Some programs are
    written as one offs to be thrown away as soon as they are run. At the
    other end of the spectrum are dusty fortran decks that have been around
    since the 60s. 

>    ALL programs shold be rewritten every so often.  There a couple of
>    reasons for this.

There are also a couple of reasons *against* this.

1. Cost.  The time and resources you spend to rewriting a program are 
not spent enhancing it.  Simply rewriting can be prohibitively 
expensive; witness Lotus 1-2-3, years late and not perceptibly better.

2. Programs are not mountains; they should not be rewritten simply 
"because they are there."  As with any other work, you should expect 
to get some advantage out of it.  Many times the effort will be worth 
the future savings in maintenance cost and (frequently) performance; 
but the benefit should be estimated and planned, not serendipitous.
If the benefit does not exceed the effort, don't do it.

3. Difficulty of duplicating functionality.  The behavior of an old 
program is generally well-known, and if it has been adequately 
maintained, it should not have many bugs.  The Macro assembler for 
TOPS-10 and TOPS-20 is an ancient (25+ years!) piece of cruft with few
comments, and is only marginally maintainable even by fairly senior
people.  However, its behavioral peculiarities are well-known by
probably millions of lines of code, and rewriting the assembler would
likely (a) be difficult and (b) break many programs. 

4. Maintenance may not equal degradation.  There is a widespread 
belief that modifications to a program are generally detrimental to 
its well-being.  A maintainer who knows his/her job will leave the 
program cleaner than he/she found it.  Granted many programs are 
maintained poorly, with a "patch and pray" attitude.  This is no 
different than designing the program poorly to begin with.

    I believe that there is a "critical mass" point in a program, at which
    adding a new feature while maintaining backward compatibilty becomes
    more difficult than coming up with a new applcation.  The moment
    critical mass is reached depends more upon how clever the originators
    of the program were than on what language they chose.  
    
    Today's tools often mean provide the equivalent of thousands of lines
    of what was previously application code.  In many CIM applications, for
    example, our group has estimated that DECdtm alone could reduce the
    amount of application code written by 40%.  
    
    
      

    Let us not forget the possibility that you may have to port the code to
    ULTRIX somewhere not too far down the road.  If you're planning a major
    revision to the thing, it's probably easiest to accept the cost of
    language conversion when you can plan for it, rather than doing it
    under the gun.
    
    -dave