Monday, June 23, 2008

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.

2 comments:

eckes said...

My definition of dynamically configurable is, that you can change settings at runtime. This requires you to be able to group changes and to do the changes without a restart. Are you sure you understood those requirements correctly?

Gruss
Bernd

Troy said...

I've done plenty of applications with configuration values that need to change at runtime. That wasn't the case here.