This is one of the hardest problems in software development, and with good reason. Naming things is how we get a handle on them, how we mark our understanding o

This is one of the hardest problems in software development, and with good reason. Naming things is how we get a handle on them, how we mark our understanding of them. It's a pivotal issue, in how it attaches our brain-maps to the problems we tackle. How many times, as a developer, have you paused and pondered what to name a new entity? I often find the difficulty of naming a thing is directly proportional to my depth of comprehension of that thing, what it does, and the context it lives in. With that in mind, I see naming-things-for-what-they-are as one winning strategy. Quoting from OP: > The problem comes in when there's a mismatch between responsibilities and names. Names are a way of expressing identity, while responsibilities are ephemeral: Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones. I find this a bit misleading, since Sam is a person with agency and a unique personality, and the things we name are, well, things, with specific purposes and raisons-d'etre. But! At the same time, OP identifies a key characteristic of things-that-persist -- scope creeps, features are added, responsibilities evolve. Naming a server "Sysyphus" may seem cheeky at first, but I'd argue that it's a better name than "Load Processing Server 2". We tend to antropomorphize things, that's one, but also - things happen over time, notable events, that create a timeline of stories which in turn build up into the coherent base of knowledge / familiarity / wisdom that ties teams together. Using "humanized" or "personalized" names pays off here, they help to glue these stories together and contribute to the institutional memory that builds up over time. In the end, I think both approaches are valid and have their place, we just have to use our judgement as to when to use which.