> You end up with the situation of not being able to say “Startrooper does <x>” because it doesn’t just do <x>.
And this leads to all the dysfunctions software engineers are supposed to care about protecting against. If a system has no high-level invariants, it is an organically evolved hairball that only a small number of Gurus, typically the people who oversaw the entire multi-year evolution of the hairball, understand or care to understand. This sets you up perfectly for endless Lava Anti-Pattern hell: only a Guru can change the system. For everyone else, the system can never be changed, only added to.
That said, point taken from the other comments saying how names can be hard to change due to external constraints. Maybe the name matters less than the discipline to make sure that "Startrooper does X and only X". Internal documentation should attempt to thoughtfully name or concisely describe the functionality of something, and if it's not possible to do so, that suggests that the system does not follow modularity best practices.
And this leads to all the dysfunctions software engineers are supposed to care about protecting against. If a system has no high-level invariants, it is an organically evolved hairball that only a small number of Gurus, typically the people who oversaw the entire multi-year evolution of the hairball, understand or care to understand. This sets you up perfectly for endless Lava Anti-Pattern hell: only a Guru can change the system. For everyone else, the system can never be changed, only added to.
That said, point taken from the other comments saying how names can be hard to change due to external constraints. Maybe the name matters less than the discipline to make sure that "Startrooper does X and only X". Internal documentation should attempt to thoughtfully name or concisely describe the functionality of something, and if it's not possible to do so, that suggests that the system does not follow modularity best practices.