A Common Phone Call

Occasionally we receive calls at the Deployment team that follow this sort of pattern:

"My application isn't working any more. It was fine yesterday, but today it's broken."

"Well, that seems a little strange as there were no changes to the environment last night."

"Oh, I forgot to mention that it's broken in UAT as well."

"When did this happen?"

"Well, this particular functionality has always been broken in UAT. We just thought that it would work when we moved to Production."

I know that some of you are laughing out there, but I also know that some of you are saying "Is he talking about me? Is he talking about ME?!?" If something doesn't work in our UAT environment, there is no guarantee that it is going to work in Production. Indeed, my bet would be that it doesn't work in Production either.

So why doesn't it work in UAT when it worked in Development? Well, unfortunately, I only have about 500 words to write an answer and in this case the answer is more like a 500 page novel. One of the biggest reasons is something we've talked about before: running something as an admin in development but with minimal rights in UAT. Just because you can run your application as an administrator on the box does not mean that you should.

I can't stress this often enough, and based on current evidence I definitely haven't, you need to run your application under the least amount of rights possible. If something doesn't work, fix it. Don't assume that there is something wrong with the environment and that it is magically going to get better when it is migrated to the next environment, as it may even get worse.