Bug Fixing Before RevDeBug
RevDeBug emerged from frustrations familiar to most developers: Bugs. In particular, finding and fixing them.
T Komp, the software company behind RevDeBug, founded in 1996, started worked on this idea after a brainstorming session. At the time, we were trying to figure out how to improve the performance of another software solution. The concept for RevDeBug emerged during that session, which is when we started exploring the problem in more detail, in 2012.
The project started to take shape in 2013 since we quickly realised we knew how to design a solution. A software development team within T Komp started working with the Polish National Centre for Research and Development (NCBR) through its Innotech program, to turn RevDeBug into a viable product, ready for consumers.
Hunting for the source of an error is not unlike trying to determine the cause of plane crashes without black box recording devices. Here is what most developers go through, every day when trying to fix a bug:
- Determine what you are looking for. Bug reports can and should give an indication, but this information isn't always clear. It is also worth checking if an error has already been reported and whether anyone else has attempted to fix the problem.
- Set up a test area, or test the known error in a live environment, so that you know where to look in the production environment.
- Ensure you know what the code is meant to do and that you can work on it within the production environment.
- Go fishing! Reproduce and diagnose the bug, so that you have a clear idea what the problem is and how to find it.
- Look for the same error throughout the production environment, where the code interacts with other product features or causes other errors to occur.
- Fix the broken code. In the process, make sure you haven't broken something else.
- Whenever possible, ensure another developer looks at the newly fixed code, to double check the work and make sure it won’t cause additional problems.
- Merge the changes in other areas of the program, to check errors won’t occur elsewhere as a result of this fix. Test the changes again.
- Ship the code live and test once more, in a live environment.
- Stop and ask yourself, how can I do this better next time? Especially if it takes a while to fix a bug. This can and should include working out how to make similar bug fixes easier in the future, including cleaning up the code or using new tools.
We know thousands of other businesses and millions of developers face these same challenges every day. RevDeBug was created to solve these problems, faster than current methods.
Above illustration is made available under the Creative Commons CC0 1.0 Universal Public Domain Dedication.Back to list