>
>re #6
>I argue there is no such thing as overuse of common code. If you have multiple copies of similar code and discover a bug in one, determining and fixing that same bug in several similar programs far outweighs any risk and you have to regression test each of those. If the spark plug is designed correctly - at design time, each instance of it at runtime will work. If you change the spark plug design, regression test the one instance in all it's test cases and it must work in all places where it is used. If something fails at runtime, you need to update your tests to handle that scenario, tweak the design, retest until the plug is perfected.
>
>re #7
>Most systems that I have seen are spaghetti - numerous strands of code dangling from a menu, with very little modularity. Most programmers start in on a new application by attempting to grok the entire bowl. Since each strand is independent, I have had lots of success walking from the menu to a single strand and effecting the change.

Mike, regarding your reply to #6, I guess, in short, your argument is in the long run it's cheaper and faster to "do it the right way". God knows how many times I've done that, i.e. fixed the same bug in multiple code fragments (only in code that was handed over to me, not code I wrote myself <grin>) However, that said, in practice, regarding function and methods I have always struggled with finding a way to identify "all places where it is used" and adequately regression test. What methodology, tools can help speed up this process?