I disagree with this, here's why: 1. If you try to make the name descriptive, it could possibly be accurate, but lack precision. To take on your example "Custo

I disagree with this, here's why: 1. If you try to make the name descriptive, it could possibly be accurate, but lack precision. To take on your example "Customer Management Tools" - ultimately there's a whole host of things all over the stack that could be considered "Customer Management Tools". Some words even come with organizational _baggage_ where stakeholders immediately think "ah we've been waiting on this for years" and you have to explain, "no this doesn't do that at all" 2. Software can change in functionality or sometimes even purpose over the course of it's life time (let's say 2-4 years, or longer). While the name is typically easy to change in user facing parts of the product, repository names and URIs are the harder parts and typically get cemented after creation. If you combine points 1 and 2, you get something that's worse than wrong or cryptic - you can get naming that is actively misleading I've seen real examples where someone started a project called "promo renderer". 3 years later new ppl onboarding onto the project will say "this renders promos? where's the code that shows the promos?" and the answer will be "well this doesn't technically render the promos, it's a configuration system which helps decides which promos get rendered; the actual render is another system". Unfortunately, it was almost impossible for the day 1 dev to see that level of nuance/precision. My final argument is not necessarily that detached names are better, but there are definitely sharp downsides which I've felt that you have not considered.