Have you heard the story of a guy that traded a paperclip for a house? It didn't happen that simply. He traded the paperclip for something else and continued trading until he eventually had a much more expensive item. When I think about what he did, I imagine he took advantage of having something that someone else needed to the point where they would trade something more valuable for the less valuable item he had. I also doubt the process he followed is very repeatable. While someone could take some of the ideas, trades for different items would need to be substituted. Furthermore, I doubt many would have his same success.
This leads me to my topic of interest today and that is repeatability. When software engineers create a program, they require a team of quality assurance (QA) engineers to test their code to look for problems. The worst kinds of problems to find are non-repeatable ones. If the program runs 9 times out of 10, it becomes the QA engineer's responsibility to figure out the exact repeatable steps to find the one time it doesn't work.
One area where this becomes increasingly difficult is when using a program that creates random numbers. The whole point of random numbers is to make things unpredictable. This is why most random number programs have two calls. The primary call provides a random number. To make sure it is repeatable, it will always provide numbers in the same order. If you ask for a single digit random number, it might first provide a 3 and the next time you call the function it returns a 5. Stopping the program and restarting it give you the same numbers in order. This is very helpful when trying to locate software bugs. The important thing to remember is to also use the second call or randomize function. This tells the program to not use the same order but instead to mix it up.
Why is this important? Several years ago I noticed that the software provided by the governing body for ski racing forgot to include the randomize function in their software. My son attended a race at Jackson Hole and had yet to complete a Super-G race. He got lumped in with all the other first-timers. The weekend had 3 individual races where all the first-timers should have been given random starting orders within their group. Starting near the front has its advantages and so one would think my son would have his start position changed randomly. Nope the 10 to 15 racers all started in the same order for each of the 3 independent races. The developer of the software never randomized the start order as he or she should have. I tried to protest but ski coaches and race organizers don't understand the nuances of software development and accepted as fact that the coding had been done correctly.
When looking for software bugs, repeatability is important. It makes it a lot easier to find problems and fix them. Just remember to add in that randomize function at the end. Otherwise you are not really creating random numbers and that is one area hackers exploit to break into systems.
