Debugging software before it is rolled out to users seems like an obvious thing to do, but then why isn’t software that can run multiple, concurrent sessions being checked? Master’s student GERARD TABONE has the answer to this question, as well as a potential solution.
Interactions with machines have become commonplace over the past 20 years, but we rarely stop to think about how they work until they don’t. One of the main reasons why this happens is because of bugs that arise during programming, which can wreak havoc on the system when something unexpected happens. That is something Gerard Tabone, through his Master of Science research work, aims to fix.
“Let’s consider a flight booking service, which usually has multiple concurrent sessions going on,” Gerard begins. “Such a system will be having interactions with numerous potential travellers at one go. In each case, the traveller will be the first to initiate the process by asking the system whether there are flights to a particular destination and how much they cost. The computer then answers and, if there are no flights, the connection with that particular traveller is terminated. But, if there are, the computer gives the traveller two options: to accept a specific flight or to reject it. This is all fine, but what happens if the system isn’t set up to terminate the session if it doesn’t receive a reply from the traveller? What happens if it waits indefinitely?”
As Gerard continues to explain, this isn’t just a problem that can arise with flight booking services, but with all systems that can run multiple sessions at the same time. Indeed, it can also be a problem when it comes to chatbots such as those seen on Facebook and the online help centres of major brands.
So what happens when a user does not stick to what is expected of them, such as asking a question when the system is expecting an answer?
“Such shortcomings can cause the whole program to crash, affecting not just the one user but all other people using it. But there’s another issue, which is that current debugging systems will not pick up on such things. Indeed, while they may tell you that there’s a semicolon missing somewhere in the code, they can’t tell you that it won’t work in these eventualities. This is because the problem isn’t in the way the program is written, but that the system is not prepared for the unexpected.”
With this in mind, Gerard is working on building a system using Elixir, which is a type of dynamic programming language frequently used for developing programs that need to run hundreds, thousands, and even millions of concurrent processes. The aim of this will be to operate in the background automatically and silently, checking that the developer’s work can indeed handle any eventuality thrown at it, and flagging things up if it can’t.
“Debugging software that runs multiple sessions is actually not widely researched and worked on across the world, which is why my computer science thesis focuses on programming language theory. Its benefits, meanwhile, will mostly be felt by developers on the backend of such software, but this will ensure fewer running problems when the software is being used by actual users, too.”
Such research continues to show how many things we take for granted when we use software that works the way it should. It is only when we start considering how much goes into creating, verifying, and monitoring it that we realise that what seems pretty straightforward is actually quite complex.
