It's 2023. I would hope all software developers would learn that hard coding specific values in your system is more likely to cause issues than not. Across the years, we've learned not everything is installed on the c: drive, or that not everyone wants to put all data in a Documents folder (or in OneDrive). We've learned that any sort of magic number is poor practice, and we ought to know that hard-coded names are problematic as well.

Yet, we still see it happening.

This week I was reading about an admin issue in the Microsoft TechCommunity. This is related to Azure Managed Instance, but it's really an In-Memory OLTP issue. That was introduced in SQL Server 2014, so I know the code for this was likely written in the 2011-2013 timeframe, but how can this type of issue get through code review and be released?

In this case, the name of a filegroup is set specifically to XTP. It's a logical name, and I'm sure that some developer thought that things might be faster with a known location. That doesn't make sense, and while this might not be an issue for most customers, I'm sure there have been some databases built with a filegroup called XTP. After all, there are companies named XTP. What about if this feature evolves to allow a second filegroup, maybe because of some distributed architecture need in the future? Are there then code paths looking for XTP or XTP2?

As much as possible, avoid coding values in your code that a user might enter as data. Names, paths, etc. Just don't do it. Use variables, which are in every language, and let those values be read from the environment. This ensures that you don't end up with weird support requests from customers because they chose the same value you did.