Spent an hour today renaming env vars across three services to make them “consistent.” Broke staging in the process because one service cached the old values. Should’ve just left the mess alone — it worked fine before I touched it.
If you are doing a rename you should have it look for the new environment variable and then fall back to the old one if it’s not set. Log an error when that occurs, and then slowly go through and remove the old environment variables in your deploy code, then remove the compatibility code
“If it aint broke don’t fix it”
“If it ain’t broke, it’s about to be.”
- $variable1
- $othervariable
- $july2014fixvariable
- $notneeded
…and finally…
*$otherothervariable
These shall be the variable names until the heat death of the universe! Blessed be! So say we all!
It doesn’t mean you made the wrong decision. Changing the names has a potential cost - you break something (this is especially risky for environment variables which have insanely global scope, no static type checking, etc.).
Not changing the names has a potential cost too - causing confusion in future, wasted time, or even bugs due to the increased chance of mistakes.
I’m currently leaving a company where they almost never clean up their messes. Tons of old unused code is just left in the repo. Causes huge wastes of time.
Don’t underestimate the potential cost of not keeping things orderly. There was a famous case (Knight Capital) caused by not cleaning up an old unused CLI flag and it cost them $440m and destroyed the company.
I’ve not done this specifically, but I know the pain of wanting to make things neat and it breaking things. Then having to live with the unsatisfying setup instead of making everything symmetrical and scratching my brain itch.
