Or Corpaorate UK!

                -----Original Message-----
                From:   Blair Wyman [mailto:wyman@vnet.ibm.com]
                Sent:   Wednesday, March 24, 1999 3:45 PM
                To:     'MIDRANGE-L@midrange.com'
                Subject:        Re: Re[2]: IBM pushing Java

                Excerpts from midrange-l: 24-Mar-99 RE: Re[2]: IBM
pushing Java Colin
                Williams@technocra (3240*) 


                > They [the decision makers] 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.  

                On the short term, I absolutely agree; it seems
indefensible to propose
                a month of work instead of a week of work.  And *if* the
current patch
                could be the 'last patch,' then the show's over for
defending a rewrite.


                Of course, that's a BIG "if"... 

                OTOH, *if* the decision makers could be convinced that a
month-long
                rewrite would: 
                        a) greatly reduce the likelihood of more patches
ever being required, or 
                        b) reduce the next N patches from a week's work
to a day's work each; 
                then they might see the benefit. 

                Of course, that's a BIG "if," too...  *8-) 

                You're sure right on that this would be an uphill
battle, and I'm afraid
                that the less technical the decision-maker is, the less
likely they are
                to buy the "futures" argument... 

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

                You try to put a price on love?  *8-) 

                But you're right -- starting over on a stable system
that's working
                "acceptably" just doesn't make economic sense.  And,
again, in a
                perfectly stable system it could *never* make sense.   

                However, in 'typical' systems--which do require
maintenance from time to
                time (tennis-shoes or an occasional python boot)--I
think it's
                reasonable to guide the decision-makers to look a little
further out... 
                Instead of asking "who'll pay at the end of the day,"
ask "will it have
                paid at the end of the decade."   

                Obviously, the long view is a tough, tough sell in "next
quarter or die"
                corporate America... 

                -blair 

                P.S. Thanks for the stimulating discussion. 
                +---
                | 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
+---


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].