Model Networks (and Other Architectures for Preventing Semantic “Nightmare” Bugs)
High blood pressure is a notorious health problem. Since it’s a vascular condition, it can trigger a range of issues across the body, but what really makes it dangerous is that it has no outward signs or symptoms. If high blood pressure is not proactively detected and treated, it most likely will continue unnoticed until it causes a disaster.
Like many terms in computer science, “semantics” comes to us from linguistics, by way of logic. It refers to the rules which define how to interpret a message (as opposed to syntax, which are the rules that define what a valid message looks like.) Put loosely, the semantics of a piece of data are the meaning of that piece of data; when you draw conclusions about the state of the world (or the possible states of the world) based on that data, you are reasoning about that data’s semantics.
You probably already have some intuition around what a semantic error feels like. It’s basically an “oops I made some assumptions about this data/API that aren’t really true” error. Common variants include: “oops I thought this method was idempotent but it’s not”, “oops I didn’t think users could be active in two teams at once but they can”, and “oops I didn’t think these events could happen in that order but they did”. Seasoned engineers tend to write few logic bugs (“the code doesn’t do what I intended it to do”), which means a lot of the bugs they do write are semantic bugs (“the code does what I intended it to do, but in the context of the larger system the thing I intended is wrong”.)This risk is especially high in larger projects, where there’s too much code to fit in any one person’s head, and developers often have to reason about models and interfaces owned by other teams.
