Replaying, not reproducing customer bugs: the business case
Finding a bug in your software is never a good thing. However the worst case scenario for a software vendor is when the bug is at a customer site.
It is a perfect storm – it will be causing problems for the customer right now and it will usually be difficult to figure out what went wrong and so be expensive and time consuming to fix.
This sort of bug severely impacts customers because they will often be unable to make any progress on what they were doing until the bug is fixed. Because of the importance of software today, such delays can lead to missed deadlines, products shipping late (or not at all) and enormous reputational damage to the customer themselves. Consequently, such bugs can lead to a breakdown in relations between the software vendor and the customer, causing cancelled contracts and loss of revenue to the vendor.
Reproducing bugs and writing test cases
Previously, in order to solve a problem reported on code running in production, developers have needed to gather information relating to the failure to write a test case and/or reproduce the bug in-house. This is time consuming and requires significant effort from the customer, who is already annoyed at the disruption to his or her work. If this method fails (which it frequently does), software vendors often have to send staff to the customer site to try to reproduce the bug in situ, negatively impacting the customer and costing them significantly in time and resources. You can end up simply running and re-running the program, just waiting for the elusive bug to re-appear and all the while the relationship with the customer is deteriorating.
After pondering this issue for some time, we believe we’ve come up with a solution that removes the need to reproduce the bug in-house.
In order to fix a bug, what developers really need is to have access to the execution history of the program up until the point at which the bug manifested itself, whether as a program crash or other visible failure. Our new LiveRecorder tool provides this, as it allows Linux programs to make a detailed recording of themselves while they are running. The resulting Undo Recording can then be sent back to developers. This enables them to debug an exact copy of the original program’s execution, on their own work machine, allowing them to track down bugs without needing to reproduce them in-house, write test cases or make time-consuming visits to customer sites.
Once an Undo Recording has been loaded into the UndoDB reversible debugger, developers have access to an exact copy of the original program’s execution history and can record, rewind and replay their code to quickly find critical bugs, increase productivity and meet development deadlines.
The result is reduced turnaround time between customers reporting bugs and fixes being released as well as decreasing the risk to time to market goals during internal testing. Given the vital importance of software, and the impact customer bugs can have, we believe that LiveRecorder solves a key business problem for vendors. Find out more about LiveRecorder use cases and integration here.