Configs Suck

Agile development is all about being  errm Agile, something a robot knows very little about. You don’t get many agile robots not even in the movies.

Configs are all about being Agile too, done well these little files of settings goodness give you a lightweight easily changeable way of modifying code behaviour without even having to release.  They are great for switching new code features on and off, when done right that is.

 

retro-robot-i-hate-configs

 

 

However in a growing application worked on by multiple teams and with developers leaving and joining teams, configs can get you into a real mess. Multiple configs with the same name scattered throughout the the application can create confusion as to which needs changing to go along with a release.

Forgetting to highlight config changes needed with a release is another common mistake that can lead to code failing on live when all seems fine on development and test environments. Hours can be spent just trying to locate a bug which only seems to exist on the live boxes. The first port of call is to blame the infrastructure that there must be something different about the live box, something which is not present on development and test.

The way around this? Simple keep it clean, tidy and in one place. There should only be one set of configs for an application. All config changes that go along with a release should be clearly flagged at the point of committing code and shouldn’t simply reside in someones head.

All this may sound simple but from experience not doing them right can really make configs suck.

Leave a Reply