Assumptions, treacherously precious
If we were to trust the internet, we’d make 35,000 choices every day (the references are lost somewhere around Sahakian & Labuzetta, 2013, but let’s not dwell too much on the exact number). How many of those decisions rely on assumptions, would you gather? On one or more things that you only hope to be true, without putting any effort to verify them…
From a wide point of view, obviously, all of them, 100%.
If you decide to make a step, you assume that the length of your legs did not change (too much). That the sidewalk puddle is not, in fact, a bottomless mud pit. That you won’t get into cross fire, and no pianos will fall on you. That the fight between the electromagnetic force (electrons in the sidewalk repelling the electrons in your shoes) against the gravitational force (between you and the whole planet) will come to a draw, without you falling to the centre of the Earth or flying to the space… You get the idea.
But as programmers and testers, we often need to give meaning to the phrases “question your assumptions,” “document the assumptions,” and “there is no such thing as a stupid idea,” that we hear from people who don’t know how we do our daily job. Such a wide point of view wouldn’t do us any good and we need to make some assumptions about the people making these suggestions.
“We” should document all assumptions...
…assuming you understand the set of things I mean when I say “all.”
Well, they are (more or less) human. Survivors of natural selection, possessing a set of rational behaviours, together with a well-studied set of heuristics. In the modern society, we call some of the heuristics cognitive biases. For some reason, we don’t call them “the mother of all premature optimizations.”
Some of the most rational survival behaviours have been optimized into an impressive network of Bayesian inference modules in the brain, with checks and balances, commonly known as emotions. Humans are “hungry” when they should eat, “tired” whey they should sleep, “righteous” when facing injustice, “afraid” when running from the enemy, and “angry” when plotting a revenge. All very rational, 12,020 years ago.
We even apply those super-optimized routines to situations when we know we shouldn’t. We over-eat, over-caffeinate, want to be right on the internet, feel like impostors when compared to senior colleagues, and we throw perfectly good monitors out of windows that are entirely too high above the ground…
The optimization most relevant for discussing assumptions is the hindsight bias. You believe that I would have made a better decision, if only I asked for a clarification explicitly, instead of making the wrong assumption. So that, in the future, I should be more careful about my assumptions. And to document them better.
Assumptions in Software Development
Our job, when writing code, can be compared to an alien language translation. The computer is like an alien being, who has to obey the laws of physics, who can calculate very fast, but who is utterly incapable of understanding even the basic assumptions of the human nature.
We make a lot of assumptions explicit. There is a reason that the specification of requirements good enough for a computer to understand is, without a fail, called “a programming language.” It ain’t called “English” and you know it, despite any snake oil sellers claiming otherwise. The relation of the “no-code” movement to no code is similar to the relation of “Democratic Republic of the Congo” to democracy, or “Artificial Intelligence” to intelligence (i.e., the relation is aspirational, not a factual description … Update 2023: oops, actually… GPT-4 probably meets all definitions of “intelligence” made before 2018 I guess — that certainly makes the job of understanding “computers” much harder now).
Non-technical people, for some reason, assume that the hard part of our job is understanding computers. It certainly takes training, but it’s not that hard to understand computers. No, the hard part is understanding humans. Making some of your assumptions explicit in the code.
Only few of the assumptions, because we share most of them with the computer. We don’t re-implement the Schrodinger equation, we trust that the protons and electrons know what they are doing, the silicon won’t become radioactive. Neither the Periodic table, we trust the molecules know what they are doing, the plastic mouse won’t self-combust. And certainly not HTTPS over TCP/IP, we (mostly) trust the thousands of programmers that created our tools. We assume that most assumptions are already taken care of by the platform.
Nevertheless, a single English sentence can be converted into thousands of lines of code. A most complex implementation can be represented by: “Only users with the correct access level should be allowed to access the restricted documents.” and a million of assumptions.
There is no way anyone can document all of the assumptions, in the wide sense. There is no way we can agree on a precise set of assumptions that all involved people will consider sufficient in the future, after a mistake will be discovered. (If there was a way to prevent the mistake, the mistake would not have happened, which is a contradiction, thus not possible, mathematically speaking. Even if you document that a mistake can happen, the hindsighted people will feel free to blame you that you assumed incorrectly whether or not it was OK to document this known issue without fixing it.)
Psychologists might not have an easy job of explaining humans to other humans. Programmers have to explain humans to computers.
Talking about assumptions
Risk management. That is the correct framework for documenting decisions. Why did we decide A instead of B? Because it was better when we considered C and D. We couldn’t measure E and we ignored F for now, though we plan to investigate F more and update the decision later if needed.
Concrete examples. Those are the correct topics to discuss deeply. How do we prevent the same mistake? How much did it cost us, can we afford to ignore it? Can we afford to ignore the current priorities if we shift our focus?
But if you ask me to document, question, or validate “all” the assumptions, be prepared for the laser lights shining from my eyes 🐱.
How big is your imagination, how much do you assume about the computers, about our users, the stakeholders? Are you familiar with similar software solutions from the past, did you base your suggestion on the past mistakes analyzed deeply, how did you measure the safety and efficacy of the treatment?
Those questions will cross my mind before I ask politely what exactly do you mean. Chances are I will come across as sarcastic, cynical, and non-cooperative. Chances are those are my defense mechanisms against the irony of receiving advice about assumptions, when my job is converting tons of human assumptions to an alien language all along. Why do you think I have been asking the 15 “nitpicking” question yesterday? Those were the assumptions you haven’t specified that I found unclear. And I documented them — I wrote code.
