[edblarney]

1, yes. 2, not really 3, no 4, not really 5, yes, but does not affect this case.

If this company runs into this kind of problem often, then something can be done, but if this is a rare occurrence, it's not so bad.

Remember dev did not 'waste' 6 days of his time, rather, it took that time for the cogs to move together on it.

And even with 1 ... it's not super clear.

[ScottBurson]

We're actually not sure about (1), as 'kevinstubbs points out.

(2) It does appear that David, the IT Director, was responsible, though he was out of town during part of the process. (What? In 2016 "out of town" means "not reachable"?)

It's on (3) that I totally agree with 'cthulhuology and disagree with you. Changing the value of an integer constant in code is far less risky than what the code reviewer demanded. As others have argued upthread, the original one-line change should have been put through to production as it was, and the additional changes should have followed later via the established process... if indeed they were truly necessary at all. (As someone else pointed out, a variable whose value changes once in 10 years probably doesn't really need to be a configuration parameter, though making it into one probably counts as a slight improvement.)

For (4), okay, here I don't entirely agree with 'cthulhuology. There is a place for enforcing standards; code review isn't just about comprehensibility.

[bzbarsky]

> What? In 2016 "out of town" means "not reachable"?

The text explicitly says David's signature was needed. Unless they have an e-signature setup, or he can locate a fax machine, it doesn't matter how "reachable" he is.

(That's assuming that "out of town" doesn't mean "on vacation", in which case "not reachable" is in fact quite reasonable.)

[anon1209]

> (As someone else pointed out, a variable whose value changes once in 10 years probably doesn't really need to be a configuration parameter, though making it into one probably counts as a slight improvement.)

I'd argue that adding a variable that changes once in 10 years is not an improvement. Config files should consist of things that actually need to be configured. Adding crap you'll never touch makes it harder to find the variables that are actually important, and also makes it harder to read and understand all available options.

Introducing configuration variables for the hell of it is analogous to writing every method to be as generic as possible; useful but not worth the risks and expenditure. Just like how we often draw the line and say "this method doesn't need to be any more generic", config variables similarly need an approach more nuanced than "move everything to the config file".

[edblarney]

"Changing the value of an integer constant in code is far less risky than what the code reviewer demanded."

This depends on context.

An integer variable can kill humans if it's the wrong variable.

Was it related to safety?

Who knows?

I'm assuming the reviewer knew what they were doing ...

Maybe some common sense all around would have helped here.