Invariably, though, when you take a look at these scripts there is some instruction somewhere that says something like, "Change lines 4 through 7 and replace with your system's filenames/menu items/personal values/whatever." The data on which the script performs its functions is embedded right in the script itself.

To me, that's just like going out and buying a DVD player with one movie factory sealed inside of the machine. It might be a great movie, but the value of the DVD player is in its ability to play any and all movies; just as the value of a software product is its ability to process any number of sets of data. Embedding the data in the script virtually eliminates any possibility that you could ever use that script again for any other purpose without having to clone it and make a second copy for yourself.

By simply separating the process portion of the script from the data portion of the script into two distinct files, you can reuse the process with different data without ever having to touch the process component again.

Exact copies are still copies
So let's say you've made the decision to pursue this path of utilizing reusable components in your application. You've clearly defined the lines between the presentation layer, the business objects, and the data access layer, and you have designed and constructed all of your business objects to be fully configurable, loosely coupled, and completely independent of both the presentation components and the underlying data. Now it is time to assemble your application for deployment.

If you now take personal copies of your reusable components and bundle them into your application in such a way that your application is the only one to have access to these particular copies, you have just succeeded in undermining all of the work that you just went through to make your objects reusable.

Reusable components are only truly reusable if, at execution time, everyone who is sharing them is pulling them from the same, shared source. If you make yourself a copy, even if it is an exact copy, you are still falling into the same basic trap as those who make themselves a copy and alter it -- you still have created another copy. You have succeeded in cloning the component!

If you've done any work designing or normalizing database schemas, you already understand the rule about storing data in more than one location. The minute that you have data in multiple locations, not only are you unnecessarily increasing your storage utilization, you have also created a situation in which the data in one place may not match the data in the other.

Now you have to deal with the issues surrounding which copy is the accurate copy and which copies are in error. Most developers understand that concept completely when it comes to data storage, yet will basically violate the very same rule when it comes to their software.

Again, the issue comes down to maintenance, and the impact of human intervention. When it comes time to upgrade a component (and let's face it -- all viable software components get upgraded at some point in their useful life), if the component exists in more than one place, each one of those places will have to be touched in some way.