I’ve been reading about Big O terminology and it is fascinating stuff. Really puts you in your place for algorithmic coding.

There are 3 Big O equation variants to be aware of –



‘oh’ is a measure of the surprise at how fast the algorithm has run. Its highest value usually occurs when a flag is incorrectly set and no test data is being processed and so also measures disappointment.

‘ah’ is measure of evasiveness when someone asks if you’ve put anything in place to prevent, e.g, an infinite loop.

‘s/f’ is a more extreme version of ‘ah’ and also measures franticity of developer activity when it is realised that the never-ending code is running on a live system hogging all the cpu with no way of stopping it.

I have also revisited work done for one of my clients. This client’s staff is predominantly composed of people who have to use computers rather than want to use them. They just want the application to work. They care not if the variables names are nice, or whether it uses a hash table or a Rolodex as a lookup. They just want the application to work. In the heat of a publicly hosted event they want simplicity and resilience over anything else. Even a slow function that works is better than a fast one that doesn’t quite do what they want.

This particular application is mainly used in front of a crowd of, er, lively people and the operators are chosen for their personality not their computer skills. It was noticed that in quiet moments some operators would explore the system and use the tried and tested method of “I wonder what this button does?” to change settings. The consequences of such changes, in accordance with the Law of Sod, often only became apparent at the worst possible moment on a Friday evening in a rammed pub.

So I added an ‘operator grade’ to each operator and then added a data-controlled feature of having buttons only enabled for certain grades of operator. Because operators can become active whilst the system is running this meant that the enabling/disabling had to be dynamic, too.

Where, you might be wondering, is this going in relation to Big O?
The function that went through the list of controls to be enabled/disabled was a prime candidate for refactoring. It was hastily written to solve the operational problem and then (as ever) other issues took a higher priority than rewriting something that was working.
Now with pubs closed and events cancelled this is an ideal time to revisit that enormous list of “Refactor this when you get a chance” bits of code. I will detail the changes shortly … 🙂