By using a hypothetical to support his argument, the author is implicitly asserting that his hypothetical is representative of the real-world situations we’re t

By using a hypothetical to support his argument, the author is implicitly asserting that his hypothetical is representative of the real-world situations we’re trying to discuss. He had the freedom to pick the strongest example possible, or several varied examples, and chose to use only this one. Specifically, he’s using the failed outcome of this hypothetical refactoring to argue that new_sequence_number should never have been broken out into a separate function in the first place because it separated the foosoft==3 case from the conditional, which made the bad refactor more likely to happen. Certainly, in this hypothetical 1500-line function, it’s possible that they would have appeared close to each other and it’s possible they wouldn’t have. In this particular case, it’s entirely possible that the refactor was made easier to execute successfully because the programmer can leverage the compiler to find all the locations that need to be updated. In the end, he’s demonstrated a flawed hypothetical procedure and asserted that it’s worse than an imagined alternative. As usual, the argument being unsound doesn’t mean the conclusion is incorrect, only that it hasn’t been demonstrated here.