Why did you need to change 8 files to add one checkbox?

Recently, I heard someone complaining that "this language is so stupid. Why do I need to touch eight different files to add one checkbox?"

Well, I don't know for sure, but I think it's probably not the language that caused it, it's probably a combination of the architecture of the solution and a misunderstanding of what they were trying to do.

In reverse order, you're almost certainly not "just" adding a checkbox. The checkbox probably represents a value that needs persisting and that has an impact on behavior elsewhere in the code base.

Therefore, it's to be expected that changes in multiple files will probably be required.

Needing to change 8 files may be a lot but I can easily imagine scenarios where that's the case. In fact, 8 may be on the low side for many applications.

I don't think it's unreasonable to assume changes in:

1. The file where the UI is defined.
2. The file where the new setting is persisted.
3. The interface (or header) file for the service/class that handles setting persistence.
4. The file with the test abstraction for the settings interface.
5. The place(s) where the new setting has an impact on code logic.
6. Any modifications to existing tests that are impacted by the new setting/behavior.
7. New tests for the new behavior.
8. All files with localized resources for the label shown next to the new checkbox.
9. Any screenshots of the UI that are now different (because of the added checkbox)
10. [User] Documentation that explains the new setting/checkbox.

I think it's how you frame the change being made that makes the number of files that might be affected as part of a single change more understandable. Knowing how many files may be changed as part of a fix/alteration can also avoid any surprises or disappointment when making the change. Especially if unfamiliar with the codebase.

Of course, not every codebase will need modifications in as many files, and it may be unlikely to change all the files at once (especially documentation and all localized files).

There's also the possibility to automate away some of the above through the auto-persistence of settings, or the use of mocks or source generators to not need to manually make simple changes.

Bonus, knowing how many files might need to be impacted as part of any singular change can also be useful before reviewing the work done as part of the change.

Ooh, just imagine recording the expected number of files to be changed as part of the initial scoping work. This would potentially also provide an extra way of measuring if expectations about the work matched up to what was actually done/required..