Undo Reverse Debugger “Pivots” to Record-Replay

I just found a story about Undo software that was rather interesting from a strategic perspective.  “Patient capital from CIC gives ‘time travelling’ company Undo space to pivot“, from the BusinessWeekly in the UK. The article describes a change from selling to individual developers, towards selling to enterprises. This is an important business change, but it also marks I think a technology thinking shift: from single-session debug to record-replay.

I wrote about the record-replay technology from Undo before (blog 1, blog 2), and how it makes perfect sense as a technology strategy.  Being able to reproduce rare failures out of huge volumes of test runs and live runs is a true revolution in terms of getting to grips with software issues.

It also indicates the problem of selling reverse debugging as something on its own – it is a nice feature but does not really scale up in usage on its own it seems to me. However, in combination with record-replay, it can really change how you debug software.  I actually think that record-replay is the more important feature that has the biggest potential impact on how to analyze and debug runtime issues in software.

I think that I have seen a similar change in emphasis from the Mozilla-spinout RR project. They started out talking about reverse debug, and then they have gone back to their actual technical roots of reproducible debug.

Update: as Robert points out in his comment below, RR started out with record-replay and then added reverse debugging based on it. Thus, it makes sense to see it making the opposite move.

I guess the conclusion here is that you really want both – record-replay and reverse-inside-a-session to have a complete offering for dealing with difficult bugs.