Four questions to ask before automating anything

These are the four questions I put to a company’s own people in the first week, before a line of software is written. They are deliberately small — the impressive questions are the easy ones to fake an answer to. Work through them with your team and mark, honestly, which description is nearer the truth today. Nothing is sent anywhere; the page keeps your answers in your own browser and nowhere else.

Isaac Correa in Madrid, in one of the restaurants of the kind Hellomatik started with — Isaac Correa, co-founder of Hellomatik. These questions came out of doing this in real companies, not out of a framework.

1 · Where is this order?

Closer to this: Somebody opens several screens and picks whichever one they trust most today. Or closer to this: One system is named as the one that tells the truth about location, and the others are recorded as copies of it.

The disagreement between systems is older than any of your software. Naming a winner does not make the other systems wrong; it makes the disagreement resolvable without a person in the middle.

2 · Can I ship this one?

Closer to this: It depends who you ask and how busy they are. Everyone knows there is a limit; almost nobody can quote it. Or closer to this: There is a single stated limit, applied identically no matter who is asking, and the cases that get around it are listed next to it.

The hard part here is never the code. It is the afternoon in which two departments discover they have been applying different limits and both were sure theirs was the policy.

3 · Why did nothing happen?

Closer to this: An excavation through logs that ends in a theory. Or closer to this: A sentence: it stopped because an approval was missing, and the record names which one.

This is the question that changes most when a company writes its rules down, and the one that never appears on anybody’s list of requirements.

4 · Who decided that?

Closer to this: A pause, a guess, and eventually somebody says that is how it has always been done. Or closer to this: A name and a date, because the rule lives somewhere that has an author and a last-modified field.

Worth more than it looks. It converts arguments about what the policy is into arguments about what it should be, and only the second kind is worth having.

Mark all four and a short reading appears here. If you have JavaScript switched off, the questions above are the whole of it — the reading only counts what you marked.

What the four questions usually turn up. The disagreement is not a failure of anybody in the picture — it is the shape of a rule that was never written down, and it is the reason this week is a conversation rather than an installation.

What to do with the answers

Ask the questions separately, of people in different departments, and write down what they say word for word. If the answers agree, you are further along than most companies and the technical work will be quick. If they do not, you have just found the project — and the disagreement is worth more than any of the individual answers, because somebody has been absorbing it personally for years.

When the answers do agree, the next list is not another question but an inventory: which actions can be undone, and who would undo them.

None of this needs me, or software, or a budget. It needs an afternoon and somebody willing to write down an inconvenient answer. The longer version of why is here, the vocabulary is here, and the method these come from is published with a DOI.