It happens quite often that a dev will write a solution to a problem based off of some perceived potential problem. And quite often it happens to be completely unwarranted and unqualified as well.
Let's take an example of a place a friend of mine used to work. I would mention them by name, but that would just be mean at this point. So my friend was getting reports of horrible DB performance in their apps and was given the task of fixing it. In his searching, he found that the data and log files were on the same partition and the bottleneck was being created there. So he went to his boss and said, We need to split these files onto separate partitions and performance will go through the roof. To which his boss responded, I'm not going to put an untested architecture in my production environment, you'll need to test it first. Now let me say that his boss was the senior DBA, not a manager-type.
Then my friend told him (in amazement at even having to say it) that it was industry-standard practice, and that it didn't need to be tested. To which the senior DBA replied, But anything could happen, so we just can't risk it. WHAT?!?!?
OK, first of all, what is "anything"? What are you specifically afraid of? Because "anything" can't happen. For instance, your DB files can't just convert themselves to Oracle files or to Excel files during the move and all of a sudden become incompatible with SQL Server. The files aren't going to suddenly start deleting records or dropping tables. So clearly "anything" can't happen. So what is it you're afraid of? Are you afraid they'll move incorrectly and become corrupt? In that case, how about I copy them and keep the originals until we've verified that they're good in the new location? Would that work for you? No? Why not? Because anything could still happen. No, it can't. Give me some more specific scenarios you're afraid of and we'll take steps to prevent them, etc.
Another time at the same gig, my friend implemented the perfect XML solution to one of their biggest problems. It was elegant, fast, and cool. It hit the trifecta. However, he, of course, had to call the XML namespace on microsoft.com, and his boss kicked the solution back because calling an external source like that wasn't safe. Anything could happen with a hacker wanting to break-in, and he just couldn't take that chance. Three weeks later, my friend turned in his notice.
Again though, what is "anything"? Because anything couldn't happen. And it's just stupid to deny an excellent solution just because it has a reference to an external source for a namespace.
IT is full of these superstitions. These decisions aren't based on fact; they're based on things going wrong in the past, and people not taking the time to even try to understand what caused them. Nobody reads anymore. And they act like computer work is part science and part religion. You deploy an SSIS package to your test box and run it. It runs just fine. The DBA goes to implement it in prod, and he starts pulling it from the source solution you used to deploy it to test with. You immediately stop him because you want it to be pulled from test instead. Why? Well, because it's already proven itself there and you feel that it's more stable code since it's already been deployed. OK, now you're just being dumb. They're being deployed from the same code base. And you argue that anything could happen to make it not deploy correctly. OK, define "anything." This is the same argument we had above. Tell me what "anything" is and we'll take steps to prevent it. Because there's nothing that could happen when deploying it from the original source that couldn't also happen when deploying it from the deployed test code.
So again, the point here is that superstition doesn't belong in computers. Sure, things go wrong, and maybe you didn't even anticipate them. But that doesn't mean that anything could happen. Because anything can't happen. You write code and deploy it. Along the way, you try to think of issues and plan for them within reason. And you go on about your day. Don't over-invent the wheel. And for everyone's sake, if you don't understand something, just ask. You'll come off far dumber if you do something stupid because you didn't understand a situation than you would if you just ask and develop the right solution.