The article is talking about mitigating risk. Unless I missed something, it doesn't restrict itself to Java, so that's an unreasonable restriction when question

The article is talking about mitigating risk. Unless I missed something, it doesn't restrict itself to Java, so that's an unreasonable restriction when questioning the author's reasoning. But I don't think it destroys the argument completely. I suppose a single-developer code base in a fully checked and compiled language that doesn't support any kind of reflection has no particular added risk from renaming vs introducing a new name. Each time you remove one of those constraints, you add a little bit of risk. If you have a giant company, it might be possible that someone is copying a jar file and calling it in a weird way that you don't expect. If your language isn't fully checked, you might correctly rename all the Typescript uses and miss a Javascript use. If the language supports dynamical calling, it might turn out that somewhere it says "if the value of the string is one of these string values, call the method whose name is equal to the value of the string". There's various IPC systems that work this way, and it will certainly be hard to atomically upgrade them. I hate that kind of code but someone else doesn't. If your language supports you doing these things, you can create as many conventions as you like to eliminate it. But someone will have an emergency and they need to fix it right now. Some people view the correct way of dealing with that problem is to insist on the development conventions, because we need to have some kind of conventions for a large team to feasibly work together. But I guess the author leans towards the side that says "if it's valid according to the language/coding environment, it might be better or worse, but it's still valid and we need to expect and accommodate it". It isn't my preference but it's a viable position - technical debt is just value if you can accommodate it without some unreasonable burden.