A developer is tasked with writing a service that will iterate through a number of records and send notifications for each one. The type of notification might be different per record, so you can imagine logic like this:
switch (record.DeliveryPreference)
{
case "email": SendEmail(record); break;
case "sms": SendSms(record); break;
}
The developer decides that some day there may be other delivery methods, so he wants to eliminate the case/switch and instead wants to be able to add additional delivery methods via configuration only:
<DeliveryMethod type="Company.Channels.Plugins.Sms.SmsClient, Company.Channels.Plugins.Sms.Library" />
<DeliveryMethod type="Company.Channels.Plugins.Email.EmailClient, Company.Channels.Plugins.Email.Library" />
...and then use type metadata (a.k.a. Reflection) to detect new delivery methods and automatically use them.
I consider this a problem-- informally named "uneven maintainability"-- because the ability to add a new DeliveryMethod via configuration is overengineered.
Why is it overengineered? Well, if the company is going to introduce a new delivery method, that is going to a big project. You'd have to get funding, source a provider, establish connectivity, open proxies and firewalls, and write the code base that uses the new connection. There is no way that is ever going to be something that is quick and easy. So here a developer has added all this complexity so he could save 30 minutes of coding from a 500-hour project, which seems of little benefit.
Meanwhile, the additional complexity could actually be harmful, for the usual reasons unnecessary complexity is harmful. But in particular one reason stands out to me. Instead of actually using the configuration as a place where developers can easily specify system parameters, it has become a document that must contain a series of magic strings in order for the system to even work. All the config files will always look the same, and if there is one letter out of place, the thing just blows up. From an information-theoretic perspective, you could say that the configuration file has increased its percentage of equivocation, meaning that the information content has gone down.
A different sort of analogy would visualize a bridge composed of planks where every other plank is rigid or flexible. The result is a bridge that is neither rigid nor flexible, but indeed weaker overall.
I could go on with examples and pros and cons and so forth, but that would be opinion-based and is not the point of this question. I am looking for terminology or engineering principles that deal with the notion of "useless flexibility" or uneven maintainability.