|
<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>
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.