President Cyril Ramaphosa has consistently stated that the extreme measures of South Africa’s lockdown have saved lives, despite it being entirely unclear, and even unlikely, that his claim is true when one considers broader aspects of the pandemic

The joys of code optimisation

By Alwyn Van Niekerk on 22 August 2007

Last Friday I had the joy of going live with code that improved the execution time of an existing piece of code by 422%, and moved it from a batch process (which took more than 30 minutes to run, and only ran three times per day) to an online real-time process, thereby enabling users a much faster turnaround time on the complete process.

More concretely, a test case that took 190 seconds to execute, now completes in +-450 milliseconds! This calls for celebration, but this also calls for reflection and inspection, and even more so, continuous inspection.

Inevitably you get the question: “So why didn’t you just do it like that in the first place?” The reality is that this system went live with the original design that suited the original requirements, and it worked, and it worked well. In any enterprise things change over time, though, and ultimately you start experiencing scalability issues that far outweighs the amount of hardware you are willing to throw at a system. I’m a stern believer in simplicity, especially in large-scale computer systems, and if a system needs massive hardware to complete its required functionality satisfactorily, then there’s something wrong (unless if you’re doing weather simulations, of course).

Past experiences have taught me that heavily used systems that fulfill very dynamic business requirements are typically bound to a three-year major refactoring/redesign cycle. These “very dynamic business requirements” are the main factors behind most system-related problems and headaches, and have given birth to myriad processes, methodologies, and acronyms to try to deal with them, but the reality is that without these business requirements, we as IT people don’t really have a justification for our salaries, as we ultimately support business and business processes.

So embrace these changes and the headaches that they bring, because ultimately they will present a situation where you can considerably improve an existing process or system, and then you can also feel like a hero for a day — a hero who earned his salary the honest way …

Alwyn Van Niekerk is a systems architect currently specialising in identity and access management, having written, designed, and architected many large-scale enterprise Java systems. He has a keen interest in Linux and OSS and the current next-generation game-console war, and frequently heads to the countryside with his wife on their motorcycles to forget completely about all of the above ...