For an external/public project? Sure! For a release code name (like Debian does), yeah why not. For internal service names? No. Not unless there's an obvious co

For an external/public project? Sure! For a release code name (like Debian does), yeah why not. For internal service names? No. Not unless there's an obvious connection to its role (ie: TrafficCop handles DOS attempts, etc) I'm working with some legacy code that followed this pattern for internal services. It's a nightmare. WTF is Bilbo, oh it handles 2fa? And what's Pippin again? And there's a dozen other examples, of course most of them are from LOTR. I literally have to maintain a mental mapping because there's no rhyme or reason to the choices. That's actively anti-developer, anti empathy and I hate it. It's not cute, fun, helpful, professional. I can't think of a single redeeming quality. Maybe it's ok for a prototype you intend to throw away because it's so ridiculous you don't want to use that name with your boss, so it encourages non attachment. If you really can't pin down a name that describes the thing you're making, maybe you don't know what you're making? Also, we can rename and/or retractor things. And we should if their responsibilities change! Edit: added distinction about internal vs external.