Einstein’s favourite means of exploring a problem was the thought experiment: setting up a hypothetical situation and working through the science behind it.
As an example (not Einstein’s), imagine you are sitting in a car, holding a free-floating helium balloon with a string that stops it hitting the ceiling. The driver accelerates away at high speed. What happens to the balloon? Try to answer that question before reading on.
The solution comes from what Einstein described as his ‘happiest thought’ – that acceleration and the force of gravity are equivalent. When the car accelerates hard, you are pushed back into your seat, and loose objects on the dashboard fly off towards you, just as if there was an extra force of gravity pulling towards the back of the car.
So, what happens to the balloon?
The obvious answer is that, just like those loose objects on the dashboard, the balloon heads backwards as the car accelerates forward. But the reality is that the balloon will move forward. The obvious answer is wrong – but if you properly make use of Einstein’s equivalence principle, it becomes clear that the balloon should head for the windscreen. What does a helium balloon do under the gravitational attraction of the Earth? It rises, rather than falling, because it is less dense than the air around it. Similarly, under the effective gravitational pull towards the back of the car, it will ‘rise’ towards the front.
In choosing the obvious answer that the balloon would act like objects off the dashboard, we are making an assumption. But by applying the correct physical description to what’s happening, we can see past that mistake. Assumptions are often the most dangerous obstacles to getting things right, whether you are solving a physics problem or writing code.
Both coder and client can be responsible for assumption fails.
The classic coder error was the Millennium Bug. Working with limited space in early computers, programmers had assumed it would be okay to store a year as two digits rather than four. This had worse implications than simply turning 2000 into 1900. Since, for instance, ages were calculated by taking birth date away from current date, this resulted in negative values, which then could crash a system making use of a number it assumed would always be positive.
Another assumption error arises with user interfaces when the designer does not anticipate what users might do. This doesn’t just apply to software. In the classic book The Design of Everyday Things, Don Norman points out ways that bad door design can cause failure when designers assume that appearance is more important than functionality. Many doors that open in one direction have pull handles on both sides, because designers like symmetry. But this means that time and time again users try to pull open a door they have to push.
A simple push plate on one side of the door would instantly fix the problem – but the designers haven’t carried out the thought experiment of how a user interacts with a door handle. Similarly, there was a phase when ‘beautifully designed’ glass doors had concealed hinges to maximise symmetry (and no ugly push plates). Users could not see where to push and often tried to open the hinge side.
When incorrect assumptions come from clients, they may be about the way that the system is going to be used, or real-life factors that differ from their understanding. When I worked in an IT department, we had examples of both. In one case, an information system was specified by HR people to be used by airline pilots. The HR professionals assumed that the system should present data in a very simple, approachable fashion. But the pilots were used to assessing a large amount of input from complex instruments. They were unhappy because they considered the interface childish.
Another example put lives at risk.
Systems calculate the load on an aircraft based on an average passenger weight. (Airlines would love to weigh their passengers, but it’s generally considered unacceptable.) One evening, a plane was taking off from a German city. It got to rotation velocity, when the pilot pulls back on the controls to take off – but nothing happened. They only just lumbered off the runway in time. There was a coin fair on in the city. Many of the passengers had their treasured purchases on their persons. The coins nearly pushed the plane beyond take-off weight.
In all these examples, those making the decisions did not carry out a thought experiment, thinking through their assumptions about how the system would be used (the HR system and the doors) or how the environment might change, whether it be a change of date or heavier passengers. Whether specifying a system for someone else to design or coding one, it’s essential to carry out the thought experiment of how it will be used, testing the assumptions that have been made, to get to an effective solution.