Debugging: the history – part 3
In the previous two articles about the history of debugging, we have described the origins of the word “bug”, as well as original methods used by program engineers in finding and eliminating software errors.
In this article, we want to talk about the innovative solutions and go on a journey of predicting the future of debugging.
Debugging: hitting the replay button
Entering the 21st century the amount of software on the market and personal computers of a significant part of the population called for new inventions in the program debugging process. Although the technology called record and replay debugging, also sometimes called “software flight recording” or “program execution recording” is with us for some years already, many companies that would benefit from introducing this method in their environments, do not yet know it, nor they are willing to change from the old ways. But what is this recording and replaying all about anyway?
Software flight recording is more of a technology-assisted method, rather than a specific software. It bases on an idea that each program runs the code every time there is a change introduced or automated. Therefore you can record snippets of that code for later. In a case something went wrong with the software, you can then look at the recording and pinpoint what has led to this mess, allowing you to repair, recover and re-run quickly. In the more technical terms, it means that it captures the state changes of the applications and throws them on a disk (local or cloud) as each instruction in a program executes. Such file, often called the recording, can be replayed as needed and debugged interactively for resolution of defects.
Why would you want such a thing, you may ask? Well, imagine you are responsible for an aerospace transportation company, and one of your planes sink into the ocean. You have no idea why so, what do you do? You try to salvage whatever you can, but specifically essential for you to is the black box of the plane. There you can see what happened, so you can provide a root cause analysis and introduce preventive actions for the future. The same rule applies with the software (hence the usage of the “flight recorder” name), with an exception that the theoretical black box magically teleports to you. It is advantageous in case of critical situations with intermittent, non-deterministic and hard-to-reproduce bugs with an ability of remote debugging on production. Using our analogy again – you can fix the plane while it plummets to the ground, preventing it from crashing completely.
There are many solutions for that sort of debugging already, with the very same functionalities described above. If you haven’t guessed, RevDeBug is one of them!
Reverse Debugging
I could not resist highlighting the name RevDeBug in the title of this chapter, and I hope you, dear reader, will forgive me for that. I am just a mere marketer after all, and our name originates from those exact words.
You may have already heard the term reverse debugging. It is also sometimes called “historical debugging” or “backwards debugging”.
Reverse debugging is a feature allowing you to step back and forth in the execution of the program, basically making you a time traveller. It is utilising the record feature, allowing you to analyse the steps that lead to a crash carefully. The method nowadays is unexchangeable with the record and replay debugging. There can be a record and replay debugging without reverse debugging, but not otherwise.
Reverse debugging as a function is implemented in various debuggers since the 2010s, however not used commonly yet due to an incorrect approach to technology. They tend to slow down the recorded program even several times. The slowdown has a significant impact on the cost of the recorded program infrastructure. Besides, the approach used by those companies requires the installation of additional components that need other excessive powers, which puts the credibility of the entire system in question. (Psst… RevDeBug does not require any additional permissions or installation of additional components, and our slowdown is around 8%).
The part where I negate the title of this article
Now we are stepping on the most modern solution ideas that go a bit outside of the usual mainframe of debugging. I am also about to stop the “history” part and start the “future” part, so perhaps I should have changed the title of this article, but for the consistency reasons, let us just deal with it and move on.
The future of debugging lies in integrated platforms for the full observability, built-in debugger, monitoring, management, developing, DevOps, while being on-premise, cloud, containerised, remote on the client devices, and everywhere you want to be integrated with an IDE of choice.
Similar to the revolution of Turbo Pascal, making it one program to do it all, such solutions will allow for a streamlined process of quick detection, prioritisation, and assignment to a debugger induced IDE for a quick resolution.
They allow you use the automatic detection, rollback, and redeployment of production failures in minutes, seeing in real-time how many users are affected by the software error, and what the financial impact is on your business. With the integrated tables, such portals could show you the impact statistics of every recorded exception. From there, you can assign the proper people to fix them and prioritise effectively. With the addition of an ability to measure the stability and performance of your application, a great addition would be an ability to view recordings in your browser without the need for an IDE. Imagine doing that from your smartphone!
There are solutions like that already on the market, but I promised myself I would stop mentioning the name of my company in every segment.
Beyond the Science Fiction
The debugging process – the past, current and future are all exciting topics. We have gone through times and saw how it changes with each new invention. Now we are on the first steps of the next era with integrated debuggers.
Who knows what future will bring? Perhaps is Artificial Intelligence debugging itself? It is exciting, although a bit scary, though. Let us see if the Skynet will bring the revolution years from now, but today we shall focus on RevDeBug.
Feel free to contact me with any feedback, some additional debugging stories, comments, or questions. There are plenty of developments in this field, and I am very keen to find out what I can learn from my readers!
Do you feel stuck in the past? Don’t let the old ways drag you down and try the revolutionary local and remote reverse debugging software for companies of all sizes and shapes! Release your software lightning-fast; no bug can stop you now!
RevDeBug allows you to inspect past state and performance profile of your applications, even directly from production environments! That is achieved with exquisite features.
Our most popular articles: