Programmers have to deal with all sorts of considerations beyond simply "how do I get this computer to do what I need it to do?"

For example, take a familiar feature from an online shop: the "add to basket" button.

As a programmer, how do I want this to function? This may seem obvious to anyone who has shopped online. A user clicks the button, the item is added to the basket.

The complexity comes in the follow-up question: What happens when the user clicks the button again? There are at least two "obvious" answers.

The first is that nothing happens. The user wanted to add the item to their basket, they’ve done so, adding it again seems like the wrong assumption.

The second is that the quantity of that item in the basket increases by one. So if the user clicks "add to basket" twenty times, they get twenty items.

Depending on the context, one of these answers is likely to be more "obvious" than the other.

A potent idea

The key concept here is a mathematical one, called idemopotency. An action is said to be idempotent if it results in the same outcome after any number of applications. In the example above, the first option is the idempotent one. The user clicks the button, and the basket goes from not containing the item to containing the item. If the user clicks again (and again, and again), the basket remains in the same state: it contains the item precisely once.

In some ways, idempotent actions can be thought of as toggle switches. A fire alarm panic button is an idempotent action: pressing once sets the state, pressing again makes no further change.

Many software bugs can stem from mismatching the context and the expected function of the software. In the shopping example, there is no generally correct answer about what the button should do, but the context will give you a hint. The user’s expectations will be wildly different if they’re ordering a quantity of nails or an expensive item of furniture, and their reaction is likely to be equally grumpy if they receive a box of one nail despite clicking the button fifty times, or are charged for two sofas thanks to an accidental double click.

Central processor

Remember, though, that computers are really just elaborate processors. They follow processes, so anything that can be a bug in software can often have an analogue in any process.

That includes in human interaction.

As a manager, I try to encourage my team to make me aware of anything that they’re worried about. That applies even if (often especially if) they believe I’ll already be aware of the thing they’re worried about.

Frankly, I’d rather fifteen people told me about the project being late than nobody. Tell me early, tell me often.

We could consider this appropriate for an "idempotent" approach: Assume that my state will be unaffected by being told about a thing multiple times.

Many of the problems I see can be traced back to a group of people deciding not to say something about a problem because they’re sure it’s a general truth, or that their saying something will have no effect on the current state.

They’re assuming they won’t be the first to act. This can be dangerous.

Just think what would happen if everyone in a burning building just "assumed" that someone had already hit the fire alarm.