Software Best Practices

Probably so. It's so complex its extremely tough to verify. I think if any code is modified by more than 20% it should be rewritten or refactored so its unrecognizable. Really though this is a code quality issue. If the changes don't break many module interfaces a rewrite wouldn't be needed...

Coincincidently, after building 3 similar products it's beneficial to adopt a product line.

This is true because because business requirements and design decisions are also reused but only if you plan for it. The impetus of a product line approach was to reuse requirements and software for similar software products. By parameterizing the actual code base a company could support a family of...

I wish I'd have seen this too. I was deeply involved in building and maintaining a Software As Service product. I think this is another solution for reuse in-the-large, albeit indirectly. I proposed a reuse approach to our problems but had the same response as you. The business focus was on growth...

Design pattern resue is one solution to the problems inherent in code reuse.

Modification of reused code is particulalry error prone. If more than 20 to 25 percent of a component is to be reused then it's more effective and efficient to rewrite it from scratch.

There are two rules of three in reuse; a) It's three times as difficult to build reuasable components as single use components. b) a reusable component should be tried out in three different applications before it'll be sufficiently general to accept in a reuse library.

Reuse in the large works best in families of related systems and thus is domain independent. This narrows the applicability of reuse in the large.

Reuse in-the-large, (components), remains a mostly unsolved problem, even though everyone agrees it is important and desirable.

This is true and may be instrumental in the software productivity gains over the last 15 years. The IDE environments include large libraries and tool boxes of basic routines.