I have this niggling suspicion that you can observe the evolution of a developer by sampling their opinions about configuration over a three to five year period. Stay with me…
In the beginning configuration seems like an awesome power. You can change the behavior of software at run time. You can put said power in the hands of users, or, as is more often the case, you can automate boring chores freeing yourself for the hard problems, the real interesting ones. Are you clever? Heck yeah.
Then, at a certain point, you observe the hard problems become maintaining the very mechanisms of configuration: the fruit born from the seed that is your inventive mind becomes a ball and chain. Changing behavior has become a tedious maintenance task in and of itself. Compound this with the fact that users haven’t taken the configuration into their own hands. You’ve just removed skill from your gig.
Ok. Fine. What to do?
I know! This job is tedious, so let’s remove some of the window dressing from this configuration nonsense. XML? Pish posh; we have YAML! That’s way fewer movements in VIM and how could we be so obtuse in the first place.
Still, after a time, you have a devil or angel or both camping on your stiff shoulder who is persistant and annoying and relentless in asking, “why are you still doing this busy work?” Sooner or later you’ll stop questioning whether this entity is a guardian angel or a personal demon and cut to the heart of the matter; Jesus H. Christ is telling you to develop software for his dad’s sake.
Executable configuration leads us back to what we should be trying to do best: solving the problems of our users. Hey! All of a sudden we’re coding again!
Do you follow this? Where are you on my proposed evolutionary timeline? Maybe it’s not too late to eschew the all-consuming fear of asteroidal impact for taking interest in finding a sustainable environmental niche.
I have to credit my colleague Steve Harman for enlightening me on this topic. I had this instinct, this configuration aversion (which mainly manifested itself through a cranky attitude), but he really brought it to the old frontal with a pithy team room rant going something like this (and I paraphrase):
Why the fuck are we using YAML for Rakefile config when Ruby has hashmaps and, um, hello today, Ruby?!
I’ll lean on Steve for concrete examples. Yesssss!
GitHub
LinkedIn
Twitter
{ 5 comments }
I'm not sure I follow grok what you're saying. Let me try to phrase it in my own words and please correct me where I go wrong. In a compiled situation like C#, the code vs. config can be a big deal depending on how you do it (you can staple your foot to the floor or it can be really liberating depending on how you go about it).
But since Ruby is essentially a scripting language (I don't mean that pejoratively), it's essentially a type of executable configuration file with a very advanced set of features. So why use YAML and ham-string yourself when you have the full power of Ruby and the essential difference in maintaining a YAML config file vs. a Ruby executable config file is nil but one (Ruby) has far more power.
That's part of it, Chad.
The larger message I was trying to get across is: I think we make our systems over configurable. Inexorably developers are, after a time, led back to code/objects being the ideal medium for configuration; because you can mix behavior with data.
I've seen a handful of systems now where the presumption of how much “run time configuration” was needed was clearly speculative and off, off, off. A better default is to solicit feedback from the user and make changes/additions in our source code and re-release.
An example: why did you spend all this time writing a business rules engine fed by XML when rules change only infrequently and where's the editor that allows users to make these changes? Maybe something like the specification pattern would have served you better and prevented you from becoming a robot who specializes in serialization.
Does that clear things up a bit?
I've been through all those stages… and I'm currently trying to grok a further stage. Sam Newman says it best
http://www.infoq.com/presentations/From-Develop...
Here, configuration is something external to the application, verifiable and changeable at runtime. It's hard to do that in code.
Julian,
It sure is. It's hard, too, to make the right decision about what parts should be application logic and what parts should rightly be configuration.
Thanks for sharing the link!
I take your point completely about way too many things being configurable. I hate seeing masses of XML where most of the values haven't changed in 5 years…
Comments on this entry are closed.