I have no idea how or where or from whom I picked up this turn of phrase. It might even have been one of my own sparks of originality. But we at Burch Technologies now refer to any situation where someone suggests connecting a DEV environment to UAT environment or doing UAT testing in a PROD environment (or any other suggestion to mix and match environments) as “crossing the streams”.
This video clip should explain why we use this phrase and why we feel it is a bad bad bad thing to do.
https://www.youtube.com/watch?v=jyaLZHiJJnE
Ah a classic moment of comedy from the 80s…but you know what’s not funny…crossing the streams between environments. Nothing good ever comes from it…and lots of bad things happen when you do. Crossing the streams bad is how bad it is when you cross the streams.
It violates so many principles of good IT management that almost none of the reasons ever given actually justify the costs, risks and complexities that follow if you do.
- It muddies the waters when it comes to deployment procedures from DEV to UAT, or UAT to PROD. If part of the solution is already deployed to part of the UAT environment its so easy for people forget the little things like that patch that was done last Thursday morning gets forgotten and now there is a regression in PROD even though it was fixed last Thursday and now the project manager thinks the IT team are bad at their jobs and why is it so hard to get software right in enterprise IT…. In other words, the outcome of every software development project needs to be nice, clean software with nice, clean, repeatable deployment procedures. If the environments are ‘mix and matched’ then the possibility of clean repeatable deployment procedures is gone…never to seen again.
- Security across environments should ALWAYS be kept completely isolated. The PROD security regime should be identical to the UAT security regime except for the credentials themselves (of course). It follows then that anyone who suggests crossing the streams is implying that a UAT environment is given access to a PROD environment and that person is insane. Just say no. Don’t do it.
- The moment you cross the streams you have to think carefully about data syncing issues and data reset issues. So you crossed from UAT to PROD during the UAT phase…that's cool…I guess (/sarcasm). What is the data reset procedure in the downstream system so that we can re test things after going to PROD. Or worse…as a BizTalk developer…the last thing I want to see in DEV is real life customer data…”oh wow, there’s someone I know…what are the chances…” kind of thing.
- So you’re building a new system and the plan is to use one environment for UAT testing and the promote it into PROD at go live…ok, what happens right after production go live when we need to UAT test a small business requirement change? What’s that you say, there’s no UAT environment now…well your small business requirement change is now 6 weeks away from PROD release while we build a new UAT environment – Btw I hope that the guy who built PROD before he quit did good documentation because otherwise how will be sure PROD and UAT are the same... No, build a proper UAT and PROD environment at the outset so the solutions can be promoted through each environment in a hygienic and repeatable way.
- So you were up late last night fixing some crappy bug on a PROD system. Good job, you fixed it in prod, NOW FIX IT IN UAT THIS MORNING AS WELL THANKS, BEFORE YOU GET DISTRACTED BY THAT BUTTERFLY. You don’t want continental drift to separate UAT from PROD so everyone has to be militant about keeping UAT and PROD identical in all respects.
Don’t cross the streams folks…just don’t do it.