Can someone explain this odd (anti)pattern?

I work for a software company, and frequently interact with client-side IT.

Very occasionally, and really only with very process-bound organizations, I run into a Policy that states that software must be installed onto D: and not C:.

No one is ever able to explain what benefit this creates.

OTOH, one lesson I've learned from 30 years in this world is that disregarding norms often exposes you to failures and issues due to brittle code or assumptions made by other tools or whatever.

Consequently, from MY POV, a policy like "apps must go on D:" should have a VERY clear benefit for it to be worth the additional hassle & loss of standardization that it brings.

What is that benefit?

(Now, again, I'm the vendor. If you want to install our tool on the Q: drive it's your choice. Our tool doesn't care. It just seems weird and wrongheaded to me and I wonder what the motivation is beyond "that's policy.")

3 comments

[ 2.7 ms ] story [ 19.4 ms ] thread

philipswood 4y ago ↗

I'm assuming the local standard is that the drive is partitioned and system/standard stuff is on C:

h2odragon 4y ago ↗

Once upon a time there was the notion that there could be a "system" volume, which could be backed up, restored, possibly even updated, independent of an "applications" volume, which would be ideally something that could be duplicated and proliferated beyond other "systems"... like Docker etc now.

It never really worked but that had nothing to do with policy.

ubermonkey 4y ago ↗

Yeah, this is what I think they're assuming, but Windows doesn't work like that.