Interlude: On assumptions

This post started out as an introduction to tomorrow’s paper choice, but when it grew too long, I decided to move it to a post all of its own…

Let’s talk about assumptions for a moment. Often implicit (if you’re really lucky, they might be made explicit and described in a ‘system model’ or similar), they have a very powerful effect which can last for years. Assumptions are especially powerful when they shape the design of lower layers in a software stack (or earlier process steps in a value chain) and then become forgotten over time. What we often forget to do is find those assumptions, and then question them. I like to think of two basic kinds of assumptions: pre-conditions and post-conditions.

Pre-conditions tell you when you can expect a certain result to hold (when a certain subsystem will behave as expected). For example, a fault-tolerant system that assumes a non-Byzantine fault model probably won’t provide all of the desired properties in the face of an active adversary. On the flip side, an impossibility result (e.g. FLP) may become possible again if you change some of the environmental assumptions:

… a slight variation of the model turns the problem from an impossible one, to one that is both possible and not particularly complex.

Post-condition assumptions are the things we are allowed to assume about the outputs of a process or layer. For example, in some networking models we may be allowed to assume that every message eventually gets delivered. Other models don’t afford this guarantee.

The reason I’ve framed it this way is that it makes it easier to see which questions to ask. In particular, if you’ve looked at module refinement you’ll know that we can make something more powerful by weakening preconditions and/or strengthening post-conditions.

Pre-condition questions:
– Does my usage of X fall within the pre-conditions? In other words, am I safe to assume any guarantees that X makes? [safety]
– What would happen if I could weaken the preconditions of X – would that open it up to usage in more places, and are any of those interesting? [opportunity]

Post-condition questions:
– Are my expectations of X valid given the post-condition guarantees it makes? (Am I relying on some property that X does not in fact guarantee). [safety]
– What would happen if I could strengthen the postconditions of X? Would that open it up to usage in more places, and are any of those interesting? Would it create an opportunity to simplify or streamline downstream components? [opportunity]

The safety questions are the ones we’re trained to ask (although we often forget). But it’s the opportunity questions that can unlock some really interesting lines of inquiry and discovery. If you can find an assumption that’s baked into an industry / value chain / software component, and that’s been there so long that people don’t even really see it, and that doesn’t necessarily have to hold any more… then chances are you’re onto something good!

This post started as an introduction to tomorrow’s paper, but when I realised it was getting too long I moved it into a post of its own. Suffice to say, coming up tomorrow is a fine example of strengthening post-conditions leading to a really interesting development…