<Climbing on my soapbox>
I agree wholeheartedly... Many shops assume that the people who write the code
will be the ones who maintain it.
Looking at industry trends, it is clear that that *is not* the case.
Maintainability must be as important as
functionality. The Garner group noted the maintenance accounts for *80%* of an
IS shop's budget. Couple that with the
average tenure of an IS professional of three years, it's easy to see why
maintainability is so important to any IS
organization. Add the speed with which business needs change, and it becomes
critical to any organization to have a
well designed and documented body of code. Anything less is "Flirtin' with
Disaster."
It's even more critical for software vendors (like IBM). Development
organizations must anticipate future needs or must
have the ability to bring upgrades to market quickly. Microsoft still needs to
learn that lesson; they seem to have
lost their speed-to-market capacity because of the number of fixes (buffer
overruns, for example) that are still
embedded in their code. They may be able to separate the browser from the
operating system but they can't separate the
buffer overruns and security holes from *all* of their applications.
When is IBM going to repackage OS/2 as a "new" alternative to MS Windows????
They could call it Windows GR for
"Gershner's Revenge." ;-)
</soapbox>
dan
-----Original Message-----
From: Richard Dettinger [mailto:cujo@us.ibm.com]
Sent: Tuesday, April 09, 2002 1:44 PM
To: java400-l@midrange.com
Subject: RE: Java Style Question
<snip>
The lesson I learned (at least sort of learned... I'm a long ways from
perfect about it yet) is that you need to write code from the start like
you expect a lot of people to use it or risk having a lot of nasty issues
on your hands trying to make it work for them later. Setter/getter methods
are a prime example of a good practice to protect yourself (there are
dozens of others).
<snip>
