Super Over Generalized

"Ya, well you can always say, I can do this thing to this thing." OverGeneralizing to the point where any two concepts/ideas could in some way be treated the same, usually resulting in sort of BruteForceSolutions, which might not scale.

Descriptive of Metametaland? (Not to be confused with Neverneverland.)

The problem with a SuperOverGeneralized solution is that as soon as your customer asks for something that doesn't conform to it's model, you're in trouble: It may to an incredibly good job of doing every possible thing, that conforms to its model, but as soon as your customer throws a wrench in the works, by giving you an unexpected requirement, life gets tough.

Sometimes it's worth it, but sometimes it's not.

Recently I was writing a Reliable Transport Protocol simulation, in which a message had to be packetized or reassembled by a couple of threads. I got into trouble when I tried viewing the jobs for the send thread (SendJob?) as the same kind of animal as jobs for the receive thread (ReceiveJob?). After doing a lot of head-scratching, I came up with a better solution by using an list of Packets for the receive jobs. The send jobs were a different sort of animal because they involved an entire message, required feedback, etc. So I eliminated the ReceiveJob? class and came up with a much cleaner solution. I forgot what the moral was... ah, well. --PatrickParker

In database design, when people start going over the edge, in terms of excessive generalization, I say, "I know!!! Lets...

Reduce the entire database design to a single table;
Give it a system-assigned numeric key,
and a large text field for the data.
Then we can put any free-form data in the text field we want, and references to other objects/records can simply use the system assigned numeric id, as text."

It truth, it would be possible to do this. Any system at all can be reduced to this kind of implementation. But you can't create any useful indexes for foreign key lookups, and processing the data can be somewhat problematic. ;->

After a while, you start to realize the value of StructuredData?: Yes, it limits what you can do, but it makes it a lot easier to actually perform useful processing on the data. -- JeffGrigg

Yeah, you read the description above (of converting the entire database to one table) and you're rolling about the floor laughing. Or not. I've been in two quite different companies where the development team did exactly this. It was painful to watch the first time, excruciating the second. Both times the company was trying to model arrays of arbitrary C structs in the database. These were 'configuration' databases. My take is that the solution wasn't SuperOverGeneralized enough... If they'd only had the courage to extend the database with the meta data features they needed, they could have stayed with multiple tables. Instead they tried to squeeze a flexible structure (the ever changing configuration data structure) into a rigid one (the single table). Bottom line, the basic unextended database features were not general enough to support what they were trying to do. -- JamesCrook

I'd vote that many many more applications are SlavishlyUnderGeneralized than SuperOverGeneralized. Applications that know more than they need about today's environment are typically much to resistant to change. I suspect the question is not is the system too generalized (whick like rich, slim, and successful is a contradiction) but is the system correctly generalized. --JimRussell