The definition of insanity is doing the same thing over and over again and expecting difference results.”

Often this is quoted to mock someone who is trying to achieve something on a computer and duplicating the exact steps multiple times with the same unsuccessful output. But take this example:

<script>
  let i = 0;
  const buttonWasClicked = () => {
    i++;
    if (i === 3) {
      console.log('third time lucky');
    }
  }
</script>

<button 
  onClick="buttonWasClicked()">
  Button of Insanity
</button>

Here we see that the console only gets activity after the third click. While this example is overtly contrived, the principle behind it (i.e. a UI that responds differently depending on a state that itself may or may not be transparent to the end user) is extremely common in software. To develop this out a bit more, there are three kinds of user interfaces in computers:

  1. UIs that have zero bugs or flaws in them. This is Unicorn territory. They almost don’t exist, and when they do, they’re extremely basic UIs that are of little value.
  2. UIs that have bugs that are manifest 100% of the time. This is also pretty rare in software that’s regularly used because the bugs are incredibly obvious and tend to get fixed. Which leads us to the most common type of UIs:
  3. UIs that have bugs that only occur some of the time. One way to think of this is that component B has a bug that in and of itself is never manifest, but becomes manifest if component A gets into a certain state. This category can be sub-divided into two smaller sections.
    1. Sometimes it is the case that component A is by default in a state that causes the bug in component B to be manifest. This results in the bug usually being present, unless you first fix the state of component A. In terms of the above example, think of the <script> as component A and the <button> as component B. The latter has no bugs in it - it correctly wires to a function on the click event. Rather, the bug resides in component A: it only performs an action on the third click (i.e. it has to be in a certain state to work), whereas the user expects the button to perform the action on every click. The button is unreliable, but not completely broken. This is the scenario in which the user gets mocked for being insane. It’s ambiguous to the user if the fix to component A is circumstantial or requires a specific change in their user behavior, but either way, they’re innately aware that component B really will work eventually, they just need to figure out how. This isn’t insanity; it’s working with a UI that was built by a fallible software developer. This is the normal life of a computer user. We’ve all done it many times, and we’ll continue to do it as long as there are computers.
    2. Other times it is the case that component A is by default in a good state, which means component B works most of the time. When your job is to perform Quality Assurance and you get the occasional ticket from a user complaining that something isn’t working, and you test it and it’s working fine, that is caused by this situation. In this case, your job is to test the same thing over and over again with the hope of figuring out what the secret is to reliably breaking it.

In the code example above, you didn’t have to change hardware devices to tease out the working state. You didn’t have to change networks, or get past a blip in the current network. You didn’t have to wait through an outage in a outbound web service. You didn’t have to log out of user A and log in as user B. You didn’t have to switch from one browser to another. Often, you have to do one or more of these things to tease an issue out and get to the bottom of it, but here you didn’t, and often in real life you don’t. You just have to do the exact same thing (from your perspective, though since we know the code, it’s not the exact same thing) more than once.

In computer science there is no such thing as truly trying the exact same thing over and over again, even when, from the perspective of someone looking over your shoulder, you seemingly are. Hardware and software are never in the same state. They are constantly in flux. When a bug is only sometimes present, you may be assured that there is some variance somewhere, and it is your job to find it. It’s time to quit mocking this as insanity; it is what computer scientists do for a living.