RE: Re[2]: IBM pushing Java

Holyfield vs Lewis. Can anyone take boxing seriously any more after that
result!!

Anyway,

Often in the patch vs rewrite argument, the decision is in the hands of
the big boss/project manager type person, who may or may not be
technical, and if not, certainly does not want to be involved in a
rewrite of something, because then he/she loses control to the
developer. 

They simply want you to make the patch, test it, and get the code out
there in the shortest time possible. In a situation like that, if you
decide to rewrite the code and turn a (for example) 1 week task into a 1
month task, your very likely asking to get your butt kicked. 

I'm sure that most companies would love to rewrite their entire systems,
but at the end of the day, whose gonna pay for it.
                -----Original Message-----
                From:   Blair Wyman [mailto:wyman@vnet.ibm.com]
                Sent:   Tuesday, March 23, 1999 6:40 PM
                To:     'MIDRANGE-L@midrange.com'
                Subject:        Re: Re[2]: IBM pushing Java

                Excerpts from midrange-l: 23-Mar-99 RE: Re[2]: IBM
pushing Java Tim
                McCarthy@softwarejun (831*) 

                >       But rewriting old code that does the job can be
fraught with 
                > bugs. In this debate, rewrite Vs patch, we always
underestimate the 
                > number of "undocumented features" we'll inevitably
introduce. 

                Oh, yes, I agree.  "Rewriting old code that does _the
job_" doesn't make
                *any* sense without some motivating change in the nature
of _the job_. 
                And, if I understand you correctly, your point that
minor changes to
                _the job_ may not merit a rewrite is well-taken, indeed.


                However, one point I'm trying to make is:  once some
change to _the job_
                becomes necessary -- and therefore code changes become
necessary --  the
                factors affecting the decision of patch vs. rewrite
should include the
                likelihood and expense of even more changes later.
There's a notion of
                'pay-me-now-or-pay-me-later' to some degree, wouldn't
you say? 

                Take another hypothetical...  If MyModule is so
convoluted that I have
                to relearn it every time I want to patch it, and it
looks like I'll be
                patching it fairly frequently, it might make economic
sense to start
                over and write the function from scratch using a more
maintainable
                design.  Do I risk adding "undocumented features" such
as poorer
                performance?  ...or changed behaviors?  ...or broken
                backward-compatibility?  You bet.  Risk vs. reward.
Cost vs. benefit. 
                Holyfield vs. Lewis. 

                BTW, what a nice euphemism -- "undocumented features" --
I'll have to
                remember that.  :) 

                -blair 

                +---
                | This is the Midrange System Mailing List!
                | To submit a new message, send your mail to
MIDRANGE-L@midrange.com.
                | To subscribe to this list send email to
MIDRANGE-L-SUB@midrange.com.
                | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
                | Questions should be directed to the list
owner/operator: david@midrange.com
                +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---