The Time Travel Method of Debugging Software
Developing programs that run seamlessly isn’t a linear task. The more intricate and complex the code, the more bugs that engineers potentially have to deal with. Studies have shown that software developers spend 35-50% of their time debugging.
Jason Laster, software engineer and founder of a startup called Replay.io, noticed the struggles developers were facing when debugging. “I joined Firefox to work on the Firefox Dev Tools debugger back in 2016. I wanted to make debugging easier and I kept running into issues where developers found breakpoints,” Laster said in an interview with The New Stack. “The way to make debugging easier is to make it feel more like adding a print statement in your code and then viewing the console logs.”
So the question that Laster tried to address was, how to make debugging more intuitive? The way to do this, he concluded, was to give developers “the ability to add print statements while debugging.” He compared this to time travel, noting that “it’s the daily record — something happening once and then be able to replay it and then add those print statements and see them in a console.”
Replay.io began as a pet project for Laster and CTO Brian Hackett but quickly began being adopted at Firefox. Making communication between engineers and the rest of the team is a part of “removing the friction between debugging and developers,” according to Laster.
GTM Lead Oliver de Albuquerque added, “You’ll actually never have to reproduce a bug ever again. You can just record it in Replay and share the URL link.”
The Appeal of Time Travel
Reverse debugging, or time travel debugging, is a concept most developers are already familiar with. Though there are different tools with varying names and features, it all boils down to the same idea: recording the whole browser session so that you can back in time to see the application’s entire state and debug retroactively.
Traditional debugging is typically a mix of educated guesswork plus applying logic. Even though it works, moving forward through code, line by line while watching for bugs, isn’t always efficient. But according to de Albuquerque, there are instances where time travel debugging can be very useful.
A demo of Replay
“Stripe published an interesting study called The Developer Coefficient study, there’s a survey highlighting close to half a developer’s time in a given week is spent on bad code, debugging, refactoring, modifying,”,” said de Albuquerque. “We’ve seen Replay being used by developer teams to dramatically reduce the productivity loss in these activities.”
“The debugging problem is really the first tangible use case that people tend to lock onto,” he continued, “because it’s a real pain [that] many developers are dealing with on a daily basis.”
Programming with Less Difficulty
By removing the preconceived notions about how challenging it is, Jason Laster is hoping to demystify programming. “We aim to make software more approachable,” 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 the engineers who can just go in and leave a comment. Now, the PM can recognize the function and identify what went wrong on their own. If anybody along the way can record the issue with Replay, then everyone downstream can look at the replay, debug it and see exactly what went wrong.”
Acknowledging that it’s easy to mistake Replay as another Session Replay tool, Laster explained how Replay differs. “On one end of the spectrum, you have something like a video recorder, then go along that spectrum a little bit further and you have something like a session replay tool and observability tool. Those kinds of tools give you some data about how the application is running, but you can’t debug in an observability tool. If you go further, you have something like Chrome Dev tools and Firefox tools where you could actually debug an element in the Elements panel or the network, the network monitor, or the console.log set of breakpoints. With Replay.io, you can record your site, replay it and dive into the lines of code – and do that in a collaborative way with your teams and even your users.”
Browsers for Developers
Replay’s developer 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 thoroughly understand our software no matter where it is running or what language it is written in. It would have been simpler to focus on one browser, but we designed Replay’s recorder to work across a range of runtimes and platforms from the start.”
According to Laster, their recorder is actually a browser.
“So when somebody makes a recording,” he continued, “they’re running our forked version of Firefox, and our version of Chrome. Plus we’re adding CI integrations like Cypress and Playwright so you can record your automated tests in Replay, adding a big productivity boost pre-production.”
Laster then went into detail about the programming that was involved to create Replay. “I wrote at least a hundred lines of in-line assembly code that intercepts the low-level system calls that the browser makes. Allocate memory, open a socket, read and write to a file — those kinds of things. We record that, and then when you’re viewing a replay, we take that browser that was used to make the recording, download the recording, give you the recording, and it thinks it’s running on a normal computer, but it’s just running in the simulation, kinda. Like The Matrix.”