I'm sure that a lot of you have may heard about "antipatterns." They're more or less the converse of "software design patterns" in that they describe a frequently repeated problem in designing a commonly-occurring solution. I've observed quite of a few of these antipatterns in the real world, but noticed that one particularly egregious (though, thankfully, rare) antipattern wasn't documented: I call it the Inner-Platform Effect.
The Inner-Platform Effect is a result of designing a system to be so customizable that it ends becoming a poor replica of the platform it was designed with. This "customization" of this dynamic inner-platform becomes so complicated that only a programmer (and not the end user) is able to modify it.
This Inner-Platform Effect has been seen here before (most recently in the Enterprise Rules Engine), but it wasn't until I read Mario's submission that I thought it was time to name and identify the antipattern.
The loan-origination system that Mario was dragged into was designed to be revolutionary: instead of relying on a programmer to make changes to the database, a user would simply need to make a few changes via the "Data Structure Modeler." I'll try to give you an idea of exactly how this ultra-dynamic storage system worked by showing a few snippets of code from the DSM:
cmd.CommandText = "SELECT * FROM tblTable WHERE Name = '" + tableName + "'"; ... cmd.CommandText = "UPDATE tblFields SET DataType = '" + newDataType + "' " + " WHERE fieldId = " + fieldId.ToString(); ... cmd.CommandText = "SELECT fieldValueId, dataValue FROM tblFieldValues " + " WHERE fieldId = " + fieldId.ToString() + " ORDER BY defaultOrder";
As you may have gathered, the DSM organized data using a structure it called a "Table". These tables had one or more Fields, with each Field having a specific "DataType". A single datum was then stored as a FieldValue. All of these were stored inside of a relational database.
Ironically, Mario was brought into the system because the client wanted to add a new Field to a form.