Enthused About: The Configuration Revolution

Maven.

Spring.

Grails.

JAXB.

Hibernate.

WHAT IS HAPPENING TO US, JAVA WORLD? Are we trying to reduce everything to XML? Should we be concerned about our future as lovers of code? WHAT DOES IT ALL MEAN?

Here's my take on "The Configuration Revolution".

In case it wasn't obvious, I'm being dramatic up there. But I have actually done some thinking lately about what the apparent rise in what I call "configuration-first development" represents in the development and testing world. 

Briefly, here are five things about this "Configuration Revolution" that I find fascinating:

1) Configuration-first development represents the ultimate in "code to the interface". Code which exposes and/or otherwise depends on configuration options is most likely leveraging a clean design. Stated another way, it's often more difficult to "hide" poorly written code or bad designs when developing within a configuration-first codebase.

2) Configuration-first development makes it easier to share and reuse code. Because the configuration space of a configurable piece of code can be formally specified (e.g., by an XML schema) and verified at compile-time, configuration-first code tends to be easier to integrate.

3) Configuration-first development reminds me of functional programming, and boy, do I love me some functional programming. In functional programming, I usually take a design approach of asking myself "What do I want this function to provide?" In the functional world, implementation details can be passed in or left for a later closure or something similar. In the configuration-first world of imperative languages, we see the same support for loose coupling, and I think that's a great thing.

4) Configuration-first development makes it possible for non-coders/new coders to do things that used to require a thorough understanding of a codebase. Let's be honest: Ever since those Excel macros came out, the business and data guys have been trying to move in on us while only possessing little nuggets of VB and SQL knowledge ... (in case anyone in those categories is reading, I'm only kidding). I think this can only be a positive thing for development effort, as it lets code authoring focus on what most would consider "cooler issues" that used to be only reserved for architects.

5) Configuration-first development might be taking us one step closer to practical application of formal methods. This point is perhaps a little more glossy-eyed than the rest, but as a model-based testing geek, I feel like I must mention it. Given the formalism of configuration formats like XML, I wonder if we're getting closer to the practical application of proving programs (or at least parts of programs) correct. Because we can constrain the configuration space, it seems that the necessary proofs would get simpler as well. The same goes for testing against these types of codebases in general, and especially testing of features provided by highly reused libraries (e.g., the Hibernate or Spring Core).

So basically, I'm ready.

What do you think?