[Dan Ingalls]
> However it is simple to state the ideal:  every fundamental relationship
> or process should only be described in one place.  To the extent that
> something appears in N places, there are N times as many chances to get it
> wrong one way or another.
> 
.... including debugging.  N copies of code means N different times finding
the same bug, as you *always* forget to update your other versions.  It's
one of my pet peeves about strongly typed languages such as C++; even with
templates, there are times when you have to write subtly different versions
of the same code to handle different derived classes.  And I'm not going to
say *anything* about Visual Basic, as I'd like to keep my Microsoft
certifications...

> The lines of code thing is just plain confusing.  Generally less is
> better, and I just don't think you cn compare systems this way.
> 
Unfortunately, people *do* compare systems this way and will continue to do
so until at least twenty years after a better method of comparison is
described.  I last looked at the O-O metrics world three or four years ago,
and there was no real agreement on what 'good' metrics were for O-O code.
Does anyone know whether there's any more agreement?  How do you measure
'progress' in projects written in O-O languages?  How does a non-technical
manager know whether his/her developers are on target?

		- Peter