Skip to main content

Going Postel


Postel's Law - also known as the Robustness Principle - says that, in order to facilitate robust interoperability, (computer) systems should be tolerant of ill-formed input but take care to produce well-formed output. For example, a web service operating under HTTP standards should accept malformed (but interpretable) requests from its clients but return only conformant responses.  The principle became popular in the early days of Internet standards development and, for the historically and linguistically-minded, there's some interesting background in this post by Nick Gall.

On the face of it, the idea seems sensible: two systems can still talk - still provide a service - even if one side doesn't get everything quite right. Or, more generally: systems can extract signal from a noisy communication channel, and limit the noise they contribute to it.

The obvious alternative to Postel's Law is strict interpretation of whatever protocol is in effect and no talking - or no service - when one side errs even slightly. Which seems undesirable, right? But, as Joel Spolsky illustrates beautifully, following Postel's Law can lead to unwanted side-effects, confusions and costs over time as successive implementations of a system are built and tested against other contemporary and earlier implementations and bugs are either obscured or backwards compatibility hacks are required.

Talking to one of my team recently, I speculated that - even accepting its shortcomings - Postel's Law can provide a useful heuristic, a useful model, for human communication. We kicked that idea around for a short while and I've since spent a little time mulling it over. Here's some still quite raw thoughts. I'd be interested in others.

I like to use the Rule of Three when receiving input, when interpreting what I'm hearing or seeing. I find that it helps me get some perspective on whether or not I have reasonable confidence that I understand and gives me a chance to avoid locking into the first meaning I think of. (Although it's still a conscious effort on my part to remember to do it.) I feel like this also gives me the chance to be tolerant.

I will and do accept input that I don't believe is correct without clarification if I'm sufficiently confident that I understand the intended meaning. Perhaps I know the speaker well and that they have a tendency to say "please QA it" over "please test it" even though the former violates my preferred "standards". Context, as usual, is important. In different contexts I might decide to question the terminology (perhaps we are engaged in a private, friendly conversation) or let it slide (for example, we are in a formal meeting where there are significantly bigger fish to fry).

Unlike most, if not all, computer systems, I am able to have off-channel communications with other parties. I can be tolerant of input that I would prefer not to be and initiate a discussion about it (now or later; based on one instance or only after some number of similar occurrences) somewhere else. My choices are not binary.

I have attempted to head-off future potential interoperability problems by trying to agree shared terminology with parties that I need to communicate with. (This is particularly true when we need a language to discuss the problem we are trying to solve.) I have seen enough failures over time in this area that when I recognise the possibility of this being an issue I will consider investing time and effort and emotional capital in this meta-task.

Can we really say that there is a standard for human-human conversations? Simply, no. But there are conventions in different cultures, social situations, times and other contexts.

Despite this, when I'm producing output, I think that I want to conform to some basic standards of communication. (I've written about this kind of thing in e.g. 1 and 2) There are differences when communicating 1:1 versus 1:n, though. While I can tailor my output specifically for one person that I'm talking to right now, I can't easily do that when, say, speaking in front of, or writing for, a crowd.

I observe that sometimes people wilfully misunderstand, or even ignore, the point made by conversational partners in order to force the dialogue to their agenda or as a device to provoke more information, or for some other reason outside the scope of the content of the conversation itself, such as to show who is the boss. When on the receiving end of this kind of behaviour, is tolerance still a useful approach?

Sometimes I can't be sure that I understand and I have to ask for clarification. (And frequently people ask me for the same.) Some regular causes of my misunderstanding include unexpected terminology (e.g. using non-standard words for things), ambiguity (e.g. not making it clear which thing is being referred to), insufficient information (e.g. leaving out steps in reasoning chains).

Interestingly, all of these are likely to be relative issues. A speaker with some listener other than me might well have no problem, or different problems, or the same problems but with different responses. An analogy for this might be a web site serving the same page to multiple different browsers. The same input (the HTML) can result in multiple different interpretations (renderings in the browser). In some cases, nothing will be rendered; in other cases, the input might have been tailored for known differences (e.g. IE6 exceptions, but at cost to the writer of the web site); in still other cases something similar to the designer's idea will be provided; elsewhere a dependency (such as JavaScript) will be missing leading to some significant content not being present.

Spolsky talks about problems due to sequences of implementations of a system. Are there different implementations of me? Or the speakers I communication with? Yes, I think there are. We constantly evolve our approaches, recognise and attempt to override our biases, grow our knowledge, forget things, act in accordance with our mood, act in response to others' moods - or our interpretation of them, at least. These changes are largely invisible to those we communicate with, except for the impacts they might have on our behaviour. And interpreting internal changes from external behaviours is not a trivial undertaking.
Image: https://flic.kr/p/BojaF

Edit: Michael Feathers wrote a piece on The Universality of Postel's Law.

Comments

Popular posts from this blog

Can Code, Can't Code, Is Useful

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "If testers can’t code, they’re of no use to us" My first reaction is to wonder what you expect from your testers. I am immediately interested in your working context and the way

Meet Me Halfway?

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Stop answering my questions with questions." Sure, I can do that. In return, please stop asking me questions so open to interpretation that any answer would be almost meaningless and certa

Not Strictly for the Birds

  One of my chores takes me outside early in the morning and, if I time it right, I get to hear a charming chorus of birdsong from the trees in the gardens down our road, a relaxing layered soundscape of tuneful calls, chatter, and chirrupping. Interestingly, although I can tell from the number and variety of trills that there must be a large number of birds around, they are tricky to spot. I have found that by staring loosely at something, such as the silhouette of a tree's crown against the slowly brightening sky, I see more birds out of the corner of my eye than if I scan to look for them. The reason seems to be that my peripheral vision picks up movement against the wider background that direct inspection can miss. An optometrist I am not, but I do find myself staring at data a great deal, seeking relationships, patterns, or gaps. I idly wondered whether, if I filled my visual field with data, I might be able to exploit my peripheral vision in that quest. I have a wide monito

Postman Curlections

My team has been building a new service over the last few months. Until recently all the data it needs has been ingested at startup and our focus has been on the logic that processes the data, architecture, and infrastructure. This week we introduced a couple of new endpoints that enable the creation (through an HTTP POST) and update (PUT) of the fundamental data type (we call it a definition ) that the service operates on. I picked up the task of smoke testing the first implementations. I started out by asking the system under test to show me what it can do by using Postman to submit requests and inspecting the results. It was the kinds of things you'd imagine, including: submit some definitions (of various structure, size, intent, name, identifiers, etc) resubmit the same definitions (identical, sharing keys, with variations, etc) retrieve the submitted definitions (using whatever endpoints exist to show some view of them) compare definitions I submitted fro

Testers are Gate-Crashers

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Testers are the gatekeepers of quality" Instinctively I don't like the sound of that, but I wonder what you mean by it. Perhaps one or more of these? Testers set the quality sta

Vanilla Flavour Testing

I have been pairing with a new developer colleague recently. In our last session he asked me "is this normal testing?" saying that he'd never seen anything like it anywhere else that he'd worked. We finished the task we were on and then chatted about his question for a few minutes. This is a short summary of what I said. I would describe myself as context-driven . I don't take the same approach to testing every time, except in a meta way. I try to understand the important questions, who they are important to, and what the constraints on the work are. With that knowledge I look for productive, pragmatic, ways to explore whatever we're looking at to uncover valuable information or find a way to move on. I write test notes as I work in a format that I have found to be useful to me, colleagues, and stakeholders. For me, the notes should clearly state the mission and give a tl;dr summary of the findings and I like them to be public while I'm working not just w

Build Quality

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "When the build is green, the product is of sufficient quality to release" An interesting take, and one I wouldn't agree with in general. That surprises you? Well, ho

Make, Fix, and Test

A few weeks ago, in A Good Tester is All Over the Place , Joep Schuurkes described a model of testing work based on three axes: do testing yourself or support testing by others be embedded in a team or be part of a separate team do your job or improve the system It resonated with me and the other testers I shared it with at work, and it resurfaced in my mind while I was reflecting on some of the tasks I've picked up recently and what they have involved, at least in the way I've chosen to address them. Here's three examples: Documentation Generation We have an internal tool that generates documentation in Confluence by extracting and combining images and text from a handful of sources. Although useful, it ran very slowly or not at all so one of the developers performed major surgery on it. Up to that point, I had never taken much interest in the tool and I could have safely ignored this piece of work too because it would have been tested by

The Best Laid Test Plans

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "What's the best format for a test plan?" I'll side-step the conversation about what a test plan is and just say that the format you should use is one that works for you, your coll

Test Now

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "When is the best time to test?" Twenty posts in , I hope you're not expecting an answer without nuance? You are? Well, I'll do my best. For me, the best time to test is when there