But... I've worked with technical writers and PhDs, technical writers (the good ones) can really easily pull analogies out of thin air to help elevate a reader's understanding, I think (maybe due to star trek) that a lot of technical PhDs are quite good at forming comprehensible analogies as well. Usually CS papers are ~40% comprehensible to the vast majority of non-CS people, this differs from more liberal artsy fields where other field pieces are taken as a given and the assumptions compound to the point where education ends up being about familiarizing yourself with all that jargon.

There are some terribly complex CS concepts (try and explain how a hash function produces essentially random output - or how private and public keys are actually computed in a manner to make private keys non-trivially derivable from public keys) and some terribly ingrained jargon (Oh, how's that SSL cert was it SHA signed?) but the effect on your topic of how these jargony terms work is usually easy to express, you don't need to know the history of POSIX to comprehend that CS people have a tool that checks if a string sorta looks like an expect format that we use everywhere, and you don't need to explain positive lookahead zero width assertions to convey that point.

Having a single clause stating "ACH (the preferred US method for bank-to-bank transfers)" would instantly clear all this up... it's also insanely relevant because the topic of the article is about what happens when bank-to-bank transfers have a recipient who is dead.