a fifteen minute conversation with a layperson about a particular code base will do just fine. "You know how a car is simple to operate, right? But you understand it has an engine and many moving parts? Well.. Twitter is just like that, and there are actually lots of small engines making sure the characters get from your keyboard to other people's eyes."

> ... you just don't want me to because then it would be obvious you are just ripping people off to make more money for yourself / company.

Agree. If your car pollutes more than other cars and runs on the blood of innocent consumers, hiding that in the explanation of how a regular car works is not an excuse.

Anyone who says "You wouldn't understand" is hiding something. If you can't explain it to me, do you even know what the fuck you're talking about?

So a guy is charged with tax accounting fraud for basically not putting some number into some entry in a spreadsheet when some external event happened, and instead putting that number into a different entry in the spreadsheet. You can't just say "you know how cars are complicated? Well so are spreadsheets. That's why this guy is guilty." Your analogy has to capture some legally-relevant dynamic of the system you are trying to explain.

Imagine your case depends on proving that only a guilty person would have failed to shard a particular database. It's not enough to just explain at the highest possible level the concept of splitting up a database. You gotta get the jury to understand it enough to know why you do it, and why it would be so out of the norm to not do it in a particular situation that the person must have had a nefarious motive.

I am not sure you can explain a buffer overflow bug that easily to a layman. That's still a trivial bug for a developper. Most of the products involved in recent financial scandals are relatively simple to finance professionals. The problem was rather pretty much always a gross under estimation of the underlying risk combined with excessive leverage.

"Imagine if I told you to go to the file cabinet and remove the 8th folder in the Mason file. Well, it turns out that the Mason file only has five folders, and neither of us were careful to think about the boundaries. So you go and count off seven folders after the first Mason, but then end up grabbing a folder that's three into the Mitchell file.

"The data on a computer is organized into ordered bytes like the file cabinet, and telling a program to go to some byte's location plus some offset can result in it accessing data that it shouldn't touch, if other safeguards aren't in place."

And that lets you Hax0r the computer because?

That's a great analogy, by the way.

"Ok, so say I need you to go and put this note of death at the end of the Mason file; that would be the 20th folder. You go to the drawer, count up to 19 from the first Mason folder and put the note there. You just ended up declaring Mr. Moriarty dead. Mr. Łeldon here will be processing credit card applications later in the afternoon; I'm pretty sure that Mr. Moriarty isn't going to get his now.

This is the way one uses the 'buffer overflow' problem in computers to manipulate data. With a little skill you can use it to do serious damage. Consider, for instance, what would happen if we were at an engineering company and slipped in a new blueprint for a machine instead of a personell note. Later someone else would pick up the design and the factory, none the wiser, would proceed to build our machine, instead of the one they wanted.

I don't buy the "you wouldn't understand" either. Here are simple explanations of a buffer overflow:

- We agree I'll give you max 1L of water, so you prepare a 1L bucket. Then I pour 2L of water into your bucket - you end up with a mess. (exploit version: We agree that if any water hits the ground, I can force you to do anything.)

- I give you card with typical form to fill in (squares for every letter). First 5 squares are for first name, next 5 are for last name. You fill in "Michael" as your first name overflowing into last name space.

- etc...

Sure, it doesn't capture all intricacies of the mechanism, implementation, side effects of the overflow, etc. But don't tell anyone they wouldn't understand the concept.

> Twitter is just like that, and there are actually lots of small engines making sure the characters get from your keyboard to other people's eyes."

That's an abstract explanation of what Twitter's code is, it doesn't get you anywhere closer to being able to actually understand the code.

Just like I wouldn't expect a layperson person to be able to find and fix a bug in a codebase, I don't think they can reliably evaluate the nuances of the financial system.

Your analogies don't help at all when it comes time to understand the details of said system, and evaluate whether or not a correct decision was made. When you need to reason about the details about a complex system, all analogies fall apart. The juries need to reason about details in a complex system and comparing Twitter to a "car engine" won't help a lay person understand why Twitter's fictional database layer is deadlocking and why the repair function shouldn't run during a transaction.

>If your car pollutes more than other cars and runs on the blood of innocent consumers, hiding that in the explanation of how a regular car works is not an excuse.

I think the takeaway here, is in the real world cars don't visibly run on the blood of innocent consumers. The means of procurement of gasoline is wrapped up in many different corporations, industries and nation-states which makes it incredibly difficult to ascertain blame.

I could make the argument that your volkswagen runs on the blood of innocent servants in Saudi Arabia. Who is at fault? Mercedes, Chevron, The Royal House of Saudi, A select few in that group, The American Government, or you?