Random functions can be useful. There is even specialized hardware in many processors for generating random numbers. That said, there are some situations where the requirements as written from a user perspective call for randomness, but I’ve learned to have an inclination to avoid it. Thinking about projects I’ve worked on over the past decade, there are instances where the requirements called for a program to make a random selection from a pool of possible selections and present it to the user. There have been times when I’ve done exactly that, only to have a bug written up and sent back to me. It is by way of these bug reports that I’ve learned new previously unstated requirements.

One bug report was about having received the same selection twice in a row. “Well, yes. It’s random, sometimes that can happen.” A new request was made for this to not happen. I added logic to prevent this, knowing that this made the selection less random; if the previous selection is informative to something about the following selection, then it is no longer completely random. In another instance, I received a bug report stating that some item or another wasn’t showing up frequently enough or something showed up too frequently. Now, I needed to keep track of the frequencies at which selections had been presented and adjust the selection process to give a higher chance to items that had a lower frequency of having been shown.

The most egregious problem I encountered was when the software was really misbehaving. For me, the problem was that the misbehaviour never occurred. I tried letting the program make a hundred cycles of selecting items, and it all worked fine. On the machine that QA was using, the problem was infrequent, but did occur. Because of the inconsistency, I decided to rip out the instances of the random function being used to make a selection and replace it with a routine that would shuffle the selections around before making a selection. The routine was deterministic, not random. But it convoluted the selection process enough to make the process perceivably random and not generally predictable to a casual observer. Most importantly of all, now the QA machine and my development machine were making the same selections in the same order. Through this, we found that the bug was only observable when a specific selection followed some other specific selection. Something that only had a 2% chance of happening.

Now, when I’m asked to make a random selection, I consider does it really need to be random, or only perceivably random. Some routines, such as the creation of identifiers such as GUIDs, do need to be random. But much of the time it doesn’t.

Posts may contain products with affiliate links. When you make purchases using these links, we receive a small commission at no extra cost to you. Thank you for your support.

Mastodon: @j2inet@masto.ai
Instagram: @j2inet
Facebook: @j2inet
YouTube: @j2inet
Telegram: j2inet
Bluesky: @j2i.net