Re: Cloning is good (was Re: How to get the help of @?)

[Israel Herraiz]

Excerpts from Sergei Steshenko's message of Sun Sep 02 22:09:55 +0200 2012:
> I have already read 15 pages of the article, and I haven't come to
> the conclusion that the article denies the importance of single
> point of change/maintenance.

The paper does not deny the importance of "single point of change". It
denies that it is always a good idea, and that not obeying that
principle is a bad sign or not a proper development methodology.

>From the abstract:

"Literature on the topic of code cloning often asserts that
duplicating code within a software system is a bad practice, that it
causes harm to the system’s design and should be avoided. However, in
our studies, we have found significant evidence that cloning is often
used in a variety of ways as a principled engineering tool."

So having a single point of change (that is, not any cloning at all)
is not always a good thing, and your "Software Engineering Principle"
is false. You can argue it is false in some cases only, but only one
case is enough (although that paper shows more than one case), it
could not qualify as a "principle", and above all, it could not be
used to accused of bad practices to developers who have been writing
successful software for years.

> The article simply explains when and where cloning makes sense.

Or in other words, when and where having a "single point of change"
does not make sense :). So it is not an universal principle, as you
implied when you said that not obeying that principle "demonstrates"
lack of "understanding of SW architecture and of proper development
methodology".

Again, my point is that "proper understanding of software engineering"
should be based on evidence, not on principles that have been
generated without empirical evidence and that are widely accepted just
because they seem like good ideas, even though nobody has ever tried
to verify if the principle holds in practice or not. In the particular
case of Octave, it is a very fine piece of "evidence", as it is a
project that has been around since years (>10) ago, and it is lively
and in constant evolution, adding new features and fixing found
bugs. So I bet that this accumulated experience is actually a better
source of "understanding software architecture and proper development
methodology", rather than unverified principles, as you claim.

Cheers,
Israel