8 ms·

> 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 rest

> 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?

lmm 7y ago
> 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.
- tempguy9999 7y ago
  > an incremental rebuild [...] should not take a significant amount of time. > But actually a config change is just as dangerous as a code change, and the same level of testing is usually appropriate Points well made, unarguably so > In my experience many - perhaps most - production outages tend to be caused by "config changes". I have no comparable experience but it sounds all too plausible and I shall bear that strongly in mind henceforth. > "Config" tends to not be treated the same way [as code] [...] From there to the end is brilliant. Thanks so much for such an excellent response. I'm going to print this out and keep it.

lmm 7y ago

> 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.

tempguy9999 7y ago
> an incremental rebuild [...] should not take a significant amount of time. > But actually a config change is just as dangerous as a code change, and the same level of testing is usually appropriate Points well made, unarguably so > In my experience many - perhaps most - production outages tend to be caused by "config changes". I have no comparable experience but it sounds all too plausible and I shall bear that strongly in mind henceforth. > "Config" tends to not be treated the same way [as code] [...] From there to the end is brilliant. Thanks so much for such an excellent response. I'm going to print this out and keep it.