The Configurable AntiPattern

I was reading through an RFP a few weeks ago, and one of the requirements that was listed in the RFP was "make it dynamically configurable."

Why did this requirement seem so familiar?

I've seen this requirement before, but disguised differently. It's that dynamic administrative feature like being able to build ad-hoc reports from any data in the database without knowing anything about the relationships or SQL. It's that feature that never makes it into the product because it's just way too costly and time-consuming to build. In the end, we always end up building a few canned reports.

I spent some time asking myself why does this dynamically, configurable requirement always pops up? The RFP writer had good intentions. If the developers just build something that is configurable to the n-th degree then it must meet the user's needs. Dynamically, configurable. It's the catch-all term to make sure every possible scenario for tomorrow is taken care of today.

I believe that this (nearly) impossible feature makes its way into most projects because someone didn't spend the time and effort to fully understand the real needs of the users. Instead of spending a little effort with the users to identify what they really need in order to do their jobs, it's just easier to ask for the dynamically, configurable thingy.

I think this has similarities to Chris Stevenson's The Editable Grid Pattern.

A quick measurement of your organization's technical skills

If your organization's senior developers write static methods for everything, then you might want to question the capability and desire of your technology leaders to learn, grow, improve and expand their understanding of their chosen profession.

How will an organization's developers be able to quickly and effectively utilize newer technologies and ideas when they haven't grasped something like Object-oriented programming in the over 10+ years that it's been in the mainstream?