The Configuration Complexity Clock (2012)
mikehadlow.blogspot.com
The Configuration Complexity Clock (2012)
1–10 of 24 posts
Re: The Configuration Complexity Clock (2012)
#2A thread from 2017: https://news.ycombinator.com/item?id=14298715
Re: The Configuration Complexity Clock (2012)
#3Good analysis but too timid in its conclusions.
At every level of complexity, hard-coding a solution is the least evil option. Your codebase is a living expression of your business rules, and it's already using the best format you have for expressing your business domain logic (if this isn't true, use a better language). When the business rules change, the codebase should change. You already need to be able to deploy code changes quickly (e.g. to fix code bugs), so having to do a release/deploy to make a change to your business logic should not be a scary proposition; if it is, improve your release process.
Hard-code everything.
Re: The Configuration Complexity Clock (2012)
#4Good analysis but too timid in its conclusions. At every level of complexity, hard-coding a solution is the least evil option. Your codebase is a living expression of your business rules, and it's already using the best format you have for expressing your business domain logic (if this isn't true, use a better language). When the business rules change, the codebase should change. You already need to be able to deploy…
Are you being sarcastic?
Re: The Configuration Complexity Clock (2012)
#5Good analysis but too timid in its conclusions. At every level of complexity, hard-coding a solution is the least evil option. Your codebase is a living expression of your business rules, and it's already using the best format you have for expressing your business domain logic (if this isn't true, use a better language). When the business rules change, the codebase should change. You already need to be able to deploy…
This is totally wrong.
Source: decades of experience.
Re: The Configuration Complexity Clock (2012)
#6Good analysis but too timid in its conclusions. At every level of complexity, hard-coding a solution is the least evil option. Your codebase is a living expression of your business rules, and it's already using the best format you have for expressing your business domain logic (if this isn't true, use a better language). When the business rules change, the codebase should change. You already need to be able to deploy…
Yes!
Source code is config which type-checks.
If you want to "reconfigure" your app while it's running, why not give it some input, rather than tracking down a textual yaml file and editing that.
Re: The Configuration Complexity Clock (2012)
#7Good analysis but too timid in its conclusions. At every level of complexity, hard-coding a solution is the least evil option. Your codebase is a living expression of your business rules, and it's already using the best format you have for expressing your business domain logic (if this isn't true, use a better language). When the business rules change, the codebase should change. You already need to be able to deploy…
This is totally wrong. Source: decades of experience.
To whoever downvoted me, perhaps you're right. At the very least I should have tried to say why.
OK, let's try and interpret the parent post in a way that makes sense to me.
If your config data is effectively embedded in code and well isolated from the rest so that it could be extracted into an ini file easily, I'd buy that. I guess you lose flexibility as you have to recompile, but ok. Perhaps it's safer too.
> and [the code is] already using the best format you have for expressing your business domain logic
Well, often a good format for an abstract statement of actions is a list or grid of data which drives the code's decisions and actions. In that sense, if you've respected that, that's part of your config file (whether external, as a file, or embedded in the code though hopefully well isolated).
If none of this is your intention, could you let me know what you're thinking, with concrete examples please?
Re: The Configuration Complexity Clock (2012)
#8Good analysis but too timid in its conclusions. At every level of complexity, hard-coding a solution is the least evil option. Your codebase is a living expression of your business rules, and it's already using the best format you have for expressing your business domain logic (if this isn't true, use a better language). When the business rules change, the codebase should change. You already need to be able to deploy…
Yes! Source code is config which type-checks. If you want to "reconfigure" your app while it's running, why not give it some input, rather than tracking down a textual yaml file and editing that.
> If you want to "reconfigure" your app while it's running
I don't think anyone was implying having a config file obviated a program restart. I'd add that restarting an unchanged executable with an altered config file is going to be considerably faster than recompiling it.
> why not give it some input
If that's not a config file, then what are you suggesting?
Re: The Configuration Complexity Clock (2012)
#9>Initially there was hope that non-technical business users would be able to use the GUI to configure the application, but that turned out to be a false hope
Entire companies, products, and developers encapsulated in one beatiful sentence.
Re: The Configuration Complexity Clock (2012)
#10Earlier quoted context omitted.
Yes! Source code is config which type-checks. If you want to "reconfigure" your app while it's running, why not give it some input, rather than tracking down a textual yaml file and editing that.
> If you want to "reconfigure" your app while it's running I don't think anyone was implying having a config file obviated a program restart. I'd add that restarting an unchanged executable with an altered config file is going to be considerably faster than recompiling it. > why not give it some input If that's not a config file, then what are you suggesting?
> I'd add that restarting an unchanged executable with an altered config file is going to be considerably faster than recompiling it.
Why should it be? We presumably have a VCS tag corresponding to the current version such that it would be very easy to check out the corresponding version and change only one file. Then an incremental rebuild with just that one file change should not take a significant amount of time. The business already needs to be able to fix code bugs quickly - hoping that any given issue could be resolved by a config change rather than a code change is not a sound strategy. So you need to have a process for deploying code fixes fast, and then you can just reuse that process.
For large systems compilation time is not actually the bottleneck for deploying a change - rather it's the testing (particularly integration testing). But actually a config change is just as dangerous as a code change, and the same level of testing is usually appropriate. In my experience many - perhaps most - production outages tend to be caused by "config changes".
> If that's not a config file, then what are you suggesting?
At some point an application does need to have dynamic behaviour in response to some form of input. But I'd argue that we're quite good at dealing with the things we see as first-class input - we know the importance of validating input before processing it, testing different input-handling code paths, and so on. "Config" tends to not be treated the same way - all too often the testers see it as part of the code and don't test config changes like other user input changes, but the coders don't test them like code changes either. It's a dangerous ambiguity; the system is made more robust by forcing everything to be one or the other.