RevDeBug helped TKomp find errors 50% faster
What TKomp achieved in collaboration with RevDeBug:
- An error that previously took 3 days to find was discovered in just 15 minutes with RevDeBug.
- RevDeBug helped TKomp to speed up the process of finding and fixing bugs by up to 50%.
- Thanks to RevDeBug, TKomp was able to release new software 20% faster.
- TKomp saved $300,000 per year and eliminated the risk of potential fines and legal consequences due to contractual obligations.
About TKomp
TKomp creates document management and enterprise resource planning systems, assisting in implementing ISO standards. It has over 24 years of experience and employs about 50 employees (mostly engineers).
TKomp has completed several hundred large projects for companies such as Philips, Bridgestone, Reckitt Benckiser, AEGON, ArcelorMittal, IKEA and Danone.
The challenges facing TKomp and why it decided to work with RevDeBug
Since TKomp’s clients use its software for crucial company processes and ERP, they require rigorous service contracts with substantial penalties if TKomp fails to immediately fix any software errors that occur.
Over the years, TKomp made significant investments in the development teams, their constant monitoring as well as the oversight on the application to eliminate software errors quickly and effectively.
TKomp had to tackle the challenge without continuous investments in hiring more developers or service staff. However, this resulted in inefficiency of the developers’ work which translated into thousands of dollars lost per month.
When one of TKomp’s clients from the insurance industry faced a problem, and the Service Level Agreement required TKomp to act quickly on the software error, finding a solution turned out to be challenging.
Despite constant investment in employee training and improving code quality, as well as growing the maintenance team, this did not provide an adequate solution to the problem. With no access to logs, an inability to download the database, and no way of recreating the production environment, it was extremely challenging to identify the root cause of the problem, even with excellent engineers on board.
Even though an error could mean only a few lines of code need to be changed, finding them is the real challenge as it could take days, or even weeks, for an entire development team to do so.
“As a Development Team Manager, I am aware that most of the bug fixes are only a few lines of code. The biggest challenge is to know where to put them.”
– Marcin Nawrocki, Chief Engineering Officer at TKomp
To speed up identifying the root cause of the issue, TKomp decided to use to first version of RevDeBug.
How RevDebug helped TKomp discover the root cause of the errors
TKomp took advantage of RevDeBug’s option to debug on production. The company released an updated version of its product, compiled together with RevDeBug, in the hope that it would bring a breakthrough.
It only took TKomp 15 minutes to discover what the source of the problem was.
“The team of our best people has been trying to figure out the root cause of the problems for almost three days, without success. When we used RevDeBug, we knew what the root of the problem was within 15 minutes. It saved us a lot of money.”
– Marcin Nawrocki, Chief Engineering Officer at TKomp
This was the first big test for RevDeBug, and TKomp branded the solution a life-saver.
Since the issue was related to the salary generation process of one of the largest insurance business companies, RevDeBug helped TKomp keep its reputation intact and avoid huge financial penalties and legal consequences.
RevDeBug addressed the most critical challenges in TKomp’s projects by providing the logs, eliminating the need to manually download a database on multiple projects at once, and helping drive efficiencies.
It also sped up the process of finding and fixing bugs by up to 50%. With RevDeBug, TKomp was able to release new software 20% faster.
This resulted in more than $300,000 saved per year, not to mention eliminating the risk of potential fines.
Thanks to RevDeBug, TKomp’s continuous development to hundreds of clients worldwide is faster and more error-proof.
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:
- Azure Functions: Overview and Common Use Cases
- How to enable error reporting and monitoring for Azure Functions
Our Linkedin profile: