The Time Travel Software Debugging Method – The New Stack


Developing programs that run transparently is not a linear task. The more complex and intricate the code, the more bugs engineers potentially have to deal with. Studies have shown that software developers spend 35-50% of their time debugging.

Jason Laster, a software engineer and founder of a startup called Replay, noticed the difficulties developers faced when debugging. “I joined Firefox to work on the Firefox Dev Tools debugger in 2016. I wanted to make debugging easier and I kept running into issues where developers were finding breakpoints,” Laster said in an interview with The New Stack. “The way to make debugging easier is to make it look like you add a print statement in your code and then check the console logs.”

So the question Laster tried to answer was: how to make debugging more intuitive? The way to achieve this, he concluded, was to give developers “the ability to add print statements while debugging.” He likened it to time travel, noting that “it’s the daily record – something that happens once, then being able to play it back, then add those printed statements and see them in a console.”

Replay started out as a project for Laster, but quickly turned into a viable product. Replay now allows its users to record and playback web applications, with developer tools most programmers are familiar with. Replay also allows users to share, comment and inspect software with their team members. Communication between engineers and the rest of the team is part of “removing friction between debugging and developers,” according to Laster.

GTM maintainer Oliver de Albuquerque added, “In fact, you’ll never have to reproduce a bug again. You can simply send the URL link to a replay.

The lure of time travel

Reverse debugging, or time travel debugging, is a concept that most developers are already familiar with. Although there are different tools with different names and functionalities, it all boils down to the same goal: to record the execution of a program at runtime so that it can be replayed and shared with members of the community. ‘team.

Traditional debugging is usually a mix of educated guesswork and applying logic. Even if it works, going through the code line by line while watching for bugs isn’t always efficient. But according to de Albuquerque, there are cases where debugging time travel can be very useful.

A demo of Replay

“There are studies where [up to] two-thirds of a developer’s time is simply spent trying to figure out the app,” de Albuquerque said. “You can imagine Replay being used by developer teams to understand the state of their application when recruiting new employees or when building and evolving engineering teams.”

“The debugging issue is really the first tangible use case that people tend to lock onto,” he continued, “because it’s a real pain. [that] many developers face on a daily basis. »

Programming with less difficulty

By removing preconceptions about programming complexity, Jason Laster became more confident in creating a developer-friendly debugging tool. “We want to make software more accessible,” he said. “We want more people to feel like they can program and do things that don’t require a math degree.”

He went on to say, “Imagine being a project manager and asking your engineer why something broke and receiving a long explanation that still leaves your question unanswered. Using Replay, they can share the URL with engineers who can just walk in and leave a comment. Now the PM can recognize the function and self-identify what went wrong. If someone along the way can log the problem with Replay, then everyone downstream can watch the replay, debug it, and see exactly what went wrong.

Acknowledging that it’s easy to confuse Replay with another browser recording tool, Laster explained how Replay differs. “At one end of the spectrum you have something like a video recorder, and then go a little further up that spectrum and you have something like a session replay tool and an observability tool. Those kinds of tools you give data on how the app is working, but you can’t debug in an observability tool. You can’t get your application from Rocket, can you? If you go any further, you have something like Chrome Dev Tools and Firefox Tools where you can actually debug an item in the Items panel or the network, network monitor or console.log breakpoint set.With Replay you can save your site , replay it down to lines of code, and then share it with others.

Browsers for developers

Replay development tools are built with React. Its backend is compatible with a multitude of runtimes, which was a goal from the start of the project.

In a blog post, Laster wrote, “Our goal is for runtimes to be replayable: we should be able to understand our software well, no matter where it’s running or what language it’s written in. It would have been easier to focus on a single browser. , but we designed Replay’s recorder to work on a range of runtimes and platforms from the ground up.

According to Laster, their recorder is actually a browser.

“So when someone makes a recording,” he continued, “they’re running our version of Firefox, our version of Chrome, our version of Node. If you want to record your tests like your Cyprus test or your playwright tests, you can save it in CI because there is a browser, ultimately this is our version of those browsers.

Laster then went into detail about the programming involved in creating Replay. “I’ve written at least a hundred lines of inline assembly code that intercepts low-level system calls made by the browser. Allocating memory, opening a socket, reading and writing to a file – that sort of thing. We record that, and then when you watch a replay, we take that browser that was used to make the recording, download the recording, give it the recording, and it thinks it’s working on a normal computer, but it just works in the simulation. Almost like Matrix.

Photo by Fatih Turan from Pexels.


About Author

Comments are closed.