Code rant: The Configuration Complexity Clock

Once I was a younger coder, simply beginning out within the huge scary world of enterprise software program, an older, much more skilled chap gave me a stern warning about onerous coding values in my software program. “They will have to alter sooner or later, and also you don’t wish to recompile and redeploy your software simply to alter the VAT tax price.” I took this recommendation to coronary heart and shortly each worth that my software wanted was loaded from an enormous .ini file. I nonetheless assume it’s good recommendation, however be warned, like most issues in software program, it’s good recommendation up to some extent. Past that time lies ache.
Let me introduce you to my ‘Configuration Complexity Clock’.
This clock tells a narrative. We begin at midnight, 12 o’clock, with a easy new requirement which we shortly code up as slightly software. It’s not anticipated to final very lengthy, only a stop-gap in some bigger strategic scheme, so we’ve hard-coded all the appliance’s values. Months go, the appliance turns into broadly used, however there’s an issue, a few of the enterprise values change, so we discover ourselves rebuilding and re-deploying it simply to alter just a few numbers. That is clearly fallacious. The answer is easy, we’ll transfer these values out right into a configuration file, possibly some appsettings in our App.config. Now we’re at 2 on the clock.
Time passes and our software is now considerably entrenched in our organisation. The enterprise continues to evolve and because it does, extra values are moved to our configuration file. Now appsettings are not enough, we’ve got teams of values and hierarchies of values. If we’re good, by now we could have moved our configuration right into a devoted XML schema that will get de-serialized right into a configuration mannequin. If we’re not so good we would have shoe-horned repeated and multi-dimensional values into some unusual tilda and pipe separated strings. Now we’re at 4 or 5 on the clock.
Extra time passes, the irritating ‘chief software program architect’ has been sacked and our little software is now core to our organisation. The enterprise guidelines develop into extra complicated and so does our configuration. Actually there’s now a substantial studying curve earlier than a brand new rent can efficiently perform a deployment. One among our new hires is a really intelligent chap, he’s seen this case earlier than. “What we want is a enterprise guidelines engine” he declares. Now this seems promising. The configuration strikes from its XML file right into a database and has its personal specialised GUI. Initially there was hope that non-technical enterprise customers would be capable to use the GUI to configure the appliance, however that turned out to be a false hope; the mapping of enterprise guidelines into the engine requires a degree of experience that just some members of the event workforce possess. We’re now at 6 on the clock.
Frustratingly there are nonetheless some enterprise necessities that may’t be configured utilizing the brand new guidelines engine. Some logical circumstances merely aren’t configurable utilizing its GUI, and so the appliance needs to be re-coded and re-deployed for some situations. Assistance is at hand, somebody on the workforce reads Ayende’s DSLs book. Sure, a DSL will permit us to write down arbitrarily complicated guidelines and remedy all our issues. The workforce stops work for a number of months to implement the DSL. It’s a substantial technical accomplishment when it’s accomplished and everybody takes a nicely earned break. Absolutely this may imply the top of arbitrary hard-coded enterprise logic? It’s now 9am on the clock.
Amazingly it really works. A number of months go by with none adjustments being wanted within the core software. The workforce spend most of their time writing code within the new DSL. After some embarrassing episodes, they now undergo an entire launch cycle earlier than deploying any new DSL code. The DSL textual content recordsdata are model managed and every launch goes by means of regression testing earlier than being deployed. Debugging the DSL code is tough, there’s little tooling help, they merely don’t have the sources to construct an IDE or a ReSharper for his or her new little language. Because the DSL code will get extra complicated additionally they begin to miss having the ability to write object-oriented software program. A few of the workforce have began to work on a unit testing framework of their spare time.
Within the pub after work somebody quips, “we’re again the place we began 4 years in the past, onerous coding every part, besides now in a a lot crappier language.”
They’ve gone across the clock and are again at 12.
Why inform this story? To be sincere, I’ve by no means seen an organisation go all the best way across the clock, however I’ve seen lots that have gotten to five, 6, or 7 and really feel appreciable ache. My level is that this:
At a sure degree of complexity, hard-coding an answer stands out as the least evil possibility.
You have already got a basic function programming language, earlier than you go down the route of constructing a enterprise guidelines engine or a DSL, or even when your configuration passes a sure degree of complexity, think about that with a slicker build-test-deploy cycle, it could be far less complicated simply to onerous code it.
As you go clockwise across the clock, the technical implementation turns into successively extra complicated. Constructing a superb guidelines engine is tough, writing a DSL is more durable nonetheless. Every additional hour you journey clockwise will result in extra complicated software program with extra bugs and a more durable studying curve for any new hires. The extra complicated the configuration, the extra management and testing it would want earlier than deployment. Quickly sufficient you’ll discover that there’s little distinction within the size of time it takes between altering a line of code and altering a line of configuration. Reasonably than a generally out there talent, akin to coding C#, you discover that your organisation depends on a really uncommon talent: understanding your guidelines engine or DSL.
I’m not saying that it’s by no means applicable to implement complicated configuration, a rules-engine or a DSL, Certainly I might leap on the likelihood of constructing a DSL given the appropriate necessities, however I am saying that it is best to perceive the implications and recognise the place you might be on the clock earlier than you go down that route.