>3. This method of writing date routines was passed down to new
>programmers. Many date routines that were written in the 80s and 90s, when
>memory was no longer a constraint, still follow the old style of dropping
>the century!! Unbelievable!!! It shows you the power of the 'tyranny of
>the past' in large organizations.
Actually, this is another classical two-edged sword. We rightfully don't
want to reinvent the wheel, so code (or design) reuse is a worthy goal,
saving us much money (cost of re-invention) and reducing errors (why take
a chance on a new implementation of something when we already have code
that has been shown to work well in thousands of applications over years
or even decades).
However, when you discover a defect in a re-used design, you probably have
propagated it _widely_, making the cost that much greater.
Anyone have the answer? :-) Not me --- I'm not that smart. I'm not sure
it's realistic to expect that people will document _all_ of the
assumptions behind their code and then review _all_ of them for
applicability when doing a new system. Probably the real issue is dealing
with the inertia in solving the problem once it was identified.
Bill
--Bill Harris Hewlett-Packard Co. R&D Productivity Department Lake Stevens Division domain: billh@lsid.hp.com M/S 330 phone: (206) 335-2200 8600 Soper Hill Road fax: (206) 335-2828 Everett, WA 98205-1298
Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>