Tech/code question

[elisheva_m]

I'm trying to write a scene where two co-workers are trouble-shooting a new custom security or encryption routine. Someone else (who isn't present) wrote the code and he will have been careful to ensure it works before sending it to them. So maybe something in the implementation of it?

The scene is dual purpose, showing their interaction growing closer while also hiding something else in plain sight. The tech part of it can be whatever is plausible and easy to convey without bogging it down in details. I am so out of touch with that sort of thing I don't know what's plausible any more.

What could go wrong with uploading the new code into their office network or onto their phones which would need a bit of trouble-shooting? The kind of thing one person might overlook and another catch. Preferably with them being literally close while they do this. And again - easy to convey without bogging it down in details. Jargon is fine.

Edit: Turns out jargon is not fine. Well it would be in the sense I meant, but that's not how it was taken. Am overwhelmed by how much I can't understand well enough to follow here, let alone distill into a few phrases. I know the readers for my lakorn-novel are non-existent but I can't swamp them with details.

Edit 2: Sorry to have bothered everyone. I'm just going to trash this. It was a stupid idea in the first place. Thank you for your time.

Comments

[jadelennox]

I had to roll back a deploy this morning because I updated the version of python used in a library, but the Dockerfile used by the kubernetes cluster in our environment only installed an older version of python. I had to:

• update my code
• find out from my coworkers what other part of our pipelines were dependent on our code so I could verify my change was good
• test the dependent part of the pipeline by running a deploy
• see the deploy failed
• see in the console logs that it was because of python version
• get help from a colleague who figured out that the old version of python was coming from an ancient Dockerfile
• create a revert pull request and get it approved
• run a fresh deploy to verify

(There are tons of such things; I'm only thinking of that one because it happened today. Version incompatability is really common. There's also "certificate expired" or "processes depended on library version with breaking changes in an essential security patch" or "us-east-1 was unreachable, etc., etc. And the cardinal rule: "it's always DNS".)

[mneme]

Yes, this is the best.

If you have someone who builds code and is diligent and competent and has time to test thing thoroughly and then the other person finds that things are broken and has to track stuff down and fix them (possibly with help), the MOST likely vector is dependency issues.

Just because someone built code that worked -perfectly- in their environment doesn't mean it will work at all on someone else's machine. Even if they are using tools expressly designed to synchronize/isolate these kinds of dependecies (like, say, Docker, package management tools, release kits, etc), that's no guarantee that there won't be some setup outside those tools that causes everything to go to heck until it's tracked down; everything from having the "wrong" version of a package, library, scripting language, or even the entire operating system to a difference in a harmless-seeming configuration, security setting, or permission setup.

[autodach]

My condolences for your deploy.
This is a really good suggestion, very flexible. Can be boiled down to "version mismatch" or "it worked on my machine" if less jargon is desired.