Configuration Interface done right

I find configuration interfaces fascinating. I’ve worked with many languages on many projects, and if nothing else, the configuration was common in all. To be more precise, problems around configuration. There is a saying that the two most difficult programming tasks are pagination and progress bars. I’d say the third is configuration. We can do it, but it’s rarely comfortable and we’re rarely proud of the solution. Now I’m not talking about small websites with 3 configurable parameters. I’m talking about e-commerce sites and enterprise death-stars. If someone reading this have never been confronted with such issues, here’s a recap of the stuff we usually need to have in the configuration parts of such system:

• Operation stuff, like ports to listen on, database connection endpoints, api endpoints, system specific credentials, locale to use, themes, etc
• Component stuff: what logger to use, what features to enable, themes, etc
• Feature stuff: localisation, themes, feature fine-tuning
• 3rd party stuff: things that are required by the third parties we use but we have no clue what they do, or personalisation of the way we use the 3rd parties.
• Random stuff that might not be configurable at all, we just didn’t want to hard-code a string because we’re told that we lose a pinky for doing such thing.

I’ve bumped into this problem again, and now I’ve set my mind on cracking this nut. I know that I will not come up with a “one solution fits all” result, I’m not even trying to. So what will I do?

Right now I’m working on testing frameworks for a maven/sbt based ecosystem with multiple project streams, each with several layers of modules. My primary goal is to solve our problems. My secondary goal is world domination peace. The solution has not yet shown itself, so don’t expect to get anything - apart from a braindump - out of this for a while. The problem lies deep in the complex space, meaning that I have no idea that what I try will work out or not. I need experiments, measurements and feedback. I need information to reduce my ignorance of the solution space.

What I know now is that technically it is possible. It might not be easy and I might face some really interesting design challenges, but this part of the problem is simply complicated. I can choose from many design patterns, configuration file formats, libraries, tools, examples, etc. In the end, it's just code. Code can take shuttles to Mars and operate rovers on the surface. Code is just a mean to an end.

My ignorance is about user experience. How would we want to use it?

Working with many developers over the years, I have learned to accept that we are amazingly lazy. If a new tool is not ridiculously comfortable to use, we will probably not prefer it over our old (bad) habits. We’ll might give the new toy a spin, but will inevitably revert to the old one once the joy of experimenting fades away. I believe that the best way to offer a programmer an alternative is to offer a simpler solution. Recognising this, we can support our fellow programmers with products they enjoy using and are happy to switch to.

If you know a way to measure joy automatically without sticking electrodes on every user, please speak up! Even if it appears hard, I will use joy - more precisely geek joy - as a measurement of success. My hypothesis is that by solving the common problems we face with configuration interfaces and providing a dead simple way to do so through, I’ll save my peers from many hours of frustration, therefore making them happy.

How will I achieve this? I don't know yet. When? Hopefully soon. I don't see point in creating yet another complicated configuration interface, there are many decent ones out there already.

Right now I have a vague set of guesses about what I want to create, which will act as hypothesises I need to prove during the process. What I can tell you now is that currently I think that a good configuration interface

• should be dead simple to use
• should support extension
• should support scopes
• should support namespaces
• should support optional configuration files for developer local configs
• should allow stating that a new configuration file should override the keys or not
• should not need an object representation in the code
• should be dead simple to use

That's all folks. That's where I'm at now. If you think I can save myself a whole lot of trouble and use a brilliant tool that I don't know of, please tell me now! Otherwise I'll save the world and blog about it.