Resources
Why It’s Time To Debug Different With Time Travel Debugging
What do we know about debugging? Most of us know it’s painful, stressful and takes up too much of our time when we just want to build things.
We also know it is becoming increasingly harder for developers to debug software due to complex orchestrations and architectures that make understanding program behavior much harder.
The Cambridge dictionary describes the meaning of the verb ‘debug’ as follows:
“to remove bugs (= mistakes) from a computer program”.
And how do we do this? By investigating what it was that went wrong and caused our program to blow up, crash or throw errors.
To find the root cause of bugs we need to work backward
Like a detective trying to solve a mystery, the natural thing to do when debugging is to follow the evidence…backward. We need to follow the trail of clues and step backward to find out where exactly in our code the mistake or error is occuring. Once we know this, we can fix it.
So why do we debug forward?
As programmers, we are curious. We must question everything. Arguably, we are naturally disruptive. And therefore, when we are trying to determine what went wrong in the past, it has to be asked, why do most of us debug forward by manually going through the entire stop-rerun-navigate cycle when we are in fact trying to simulate stepping backward in our code to see what went wrong?
It may be a habit, but it fundamentally doesn’t make sense in the context of striving to be fast and efficient.
Traditional methods of debugging and analyzing code are no longer sufficient for the challenges of understanding complex code bases and debugging applications. They were designed for assembler circa 1972 and have remained fundamentally unchanged since then.
The most inefficient part of traditional debugging stems from working forward from the point of the crash/error. This way of working is slow and results in the need to repeatedly restart the program with different breakpoint locations.
But what if you could simply and easily time travel backward?
Debug Different with UDB
UDB delivers an entirely different workflow from normal traditional debugging. With UDB, developers can simplify troubleshooting by deterministically recording and replaying a program’s behavior. UDB gives developers the ability to time travel backward (and forward) in the code execution to the origin of the failure without repetitive guesswork, restarts and stops.
Time travel debugging is a game changer!
The ability to do time travel – i.e. stepping freely both forward and backward through program execution – drastically reduces the amount of time invested in troubleshooting your code. It’s a no brainer! Time travel debugging is also commonly known as reverse debugging.
It’s about going backward
“It’s the economy, stupid” is a phrase coined by Bill Clinton’s campaign strategist, James Carville in 1992. In political terms, he was pointing out, arguably the most important issue that people cared about that would influence their voting behavior.
We won’t be calling anyone stupid here at Undo, but we would challenge that it’s time to upgrade your method of debugging by half a century!
Our clear call to arms to software engineers out there is: if you’re in the business of finding and fixing bugs quickly and efficiently … step back in your code execution to see what happened.
Find out more about UDB and help yourself to a free trial!
