What Should Your Software Never Do?

Software design focuses on making systems work, but it has no discipline for the opposite question: what should our systems never do? Bugs and security vulnerabilities keep breaking the assumption that software only does what we program it to do.

Topics covered:

Why we design positive behavior and leave the negative space unbounded
Constraints-driven development: a second pass after “make it work”
A thought experiment: an interception layer around every module that checks negative assertions
Three forms of negative assertions: never do X, never reveal Y, never do X except for an allow list
How to fill the list: deny by default, ask per channel what must never pass through it, then add from threat models and incidents
Why the ideal is hard to build, and what already exists: architecture tests, OS permissions, firewalls

Every module has a list of things it should never do. Most teams just haven’t written it down.