I'm working for a company where our design team has elected to use "Field1".."Field10" as generic, future purposed columns. I have queried them as to the reason and was told that they are there in case we need them in the future.
Has anybody heard of this practice? Is it wrong for my jaw to drop to the floor when I see something like this?
You are not wrong at all. Not sure what the difficulty is in writing an ADD COLUMN change script.
If these are columns that are not being referenced by the application (and can not used by it at all), then this is the worst kind of YAGNI abuse.
However, if this is a product that will be deployed at maintained by people not in your company, it makes sense to put such place holders (assuming the application "knows" how to access and use them) for future unforeseen expansion.
In practice? Well, there's this little set of applications called "Oracle eBusiness" that has boatloads of columns with names like ATTRIBUTEn, where n runs from 1 - 20 or more. The application configuration on top of those gives business meaning to them, but that's what the tables look like underneath.
On the other hand, some applications create custom database tables on the fly - this requires more sophistication in some of the code, but less in others (and, IMHO, less configuration silliness). Just be glad you don't have some sort of craziness where all custom fields are stored in a single key-type-value table - I've seen that too, and it's just wrong.
Encountered it, yes, even in so called commercial products. Generally it happens when people don't really understand relational databases, and don't care about future maintenance costs.
Granted, relational databases aren't really great at handling future proofing. You generally need to evolve the schema and provide data migration paths for upgrades. This can seem more complicated and expensive up front, but compared to anonymous columns without any kind of data integrity checks... groan!