Debugging a .NET application (or any application for that matter) is a team . At the very least, you have a QA professional identifying and reporting the bug, and a developer fixing it. But often, there are more people involved. There can be a chain of command that goes through team leads and beyond, and sometimes DevOps also needs to be involved. It’s one thing for a developer to debug her code while she’s developing it, it’s quite different once that code has been committed and starts moving up the release pipeline to QA, Staging and Production.
A typical bug report is a disparate collection of data
When QA submits a bug report, the tester must include as much information as possible to make it easy for the developer to understand, analyze and fix. QA will start with a description, screenshots and the relevant log files. Those are the easy ones. But then, what about the call stack? QA might have to generate a dump file to get that. And how about the network requests leading up to the error. Those aren’t always readily available. And what about database requests? The point is that a bug report is indeed a disparate collection of data, often insufficient, requiring the developer to spend precious time trying over and over to reproduce the bug, and avoid their natural urge to proclaim the classic “It works on my machine!”, mark the Work Item as Done, and move on with their day.
Globalization, telecommuting, and the occasional plague keep us apart
The concept of a team and how we work together has vastly changed over the last few decades. “9-5 at the office with my team” is a thing of the past with more and more people working remotely. One reason for this shift is globalization. Companies are becoming more geographically dispersed. A typical software project could have development being managed from California but executed in Ukraine with QA being done in India. Another reason is a growing acceptance for telecommuting. Companies understand the costs of employees spending an hour or more getting to and from work. They have realized that a developer can now work at home one day a week and be very productive while improving her work-life balance. And then there are sick days. Recently, COVID-19 is dominating the news worldwide, putting thousands in isolation in their homes. While coronavirus is the current culprit, many of you will remember the SARS epidemic of 2003, or the H1N1 Swine Flu pandemic of 2009-2010 that affected hundreds of millions worldwide. Every few years, the latest bio-bug will take its toll on global productivity. But it doesn’t take a front-page virus to keep someone at home. People get sick or injured all the time – too sick to come in, perhaps, but well enough to work at home.
Collaborative .NET debugging with Ozcode Production Debugger
While Ozcode can’t put you in the same room literally, we try to do so figuratively with the Collaboration Panel in the Ozcode Production Debugger. The ability to collaborate effectively on a bug can’t be understated. We try to make it as easy as possible a) by providing a single shareable link that shows everyone involved with the full context of the error in question, including a recording of the code execution flow that led to the exception allowing time-travel debugging and b) through the Collaboration Panel, which facilitates effective and on-point communication between everyone by keeping the relevant conversation in one place so that the team can quickly reach consensus on what the root cause of the bug was, and what’s the best possible fix for it.
Let’s see it in action
In our example, we have a simple online store in which shipping charges of 10% are added to the cost of any purchased item. Collaboration begins when QA finds a bug and immediately notices that a new exception in the Ozcode Production Debugger Dashboard.
Clicking the bug lets Mendi, our QA engineer, drill down into the full context of the error. He writes a note in the Collaboration Panel with a “@mention” to Michael, the Dev lead.
Michael, the Dev lead, gets an email about it with a direct link to the exact same screen Mendi, our QA engineer, was looking at. He sends an “ack” to Mendi, and passes the bug over to Lyle, the developer, noting some problem with the factor used to calculate shipping costs.
With Lyle @mention’ed, he will also get an email with a direct link to the same screen. Upon clicking the link, Lyle quickly sees the problem and responds to Michael.
Michael acknowledges and closes off the conversation. Lyle can now go ahead, make the fix and submit the pull request.
So, while Visual Studio Live Share enables wonderfully convenient synchronous collaboration when two or more developers connect remotely at the same time, Ozcode Production Debugger adds the ability for asynchronous collaboration across different time zones. The physical separation between Mendi, Michael, and Lyle was completely irrelevant. They were effectively in the same room. Now, there are a few things to notice here:
- Lyle was debugging the actual decompiled code that ran in the live system where the bug was caught – QA, staging, or production.
- It only took a “@mention” in the Collaboration panel to point Lyle to the exact location in the running code that triggered the exception
- There was no need to check versions, checkout the specific Git branch on which the bug manifested, run builds, check logs, or anything. Everything Lyle needed was right there in front of him:
- variable values
- code execution flow enabling time-travel debugging of everything that happened up to the exact place that threw the exception and, of course…
- the relevant code in the exact version that was in QA, Staging or Production at the moment of failure.
Basically, everything Lyle needed for a root cause analysis and rapid resolution was put in front of him as soon as he clicked the link he got in his email.
The new technology for collaborative .NET debugging
With the ideal of face-to-face collaboration not always possible, technology has tried to come to the rescue in the form of widely available, fast internet connections, and advanced video conferencing capabilities. The future promises even greater advances with innovations like holoportation and VR-based remote conferences. But these technologies can only go so far. They can’t overcome large differences in time zones. And while internet connectivity is great in some places, it can be intermittent in others – even within the same country. And then, there’s the simple problem of scheduling conflicts that hinder collaborative efforts to fix a bug.
Ozcode Production Debugger overcomes these obstacles. With a common Collaboration panel placed right next to the relevant code, together with all other information needed, Ozcode provides a consistent and cohesive debugging experience to all team members collaborating to fix a bug. Whatever your workflow, and whatever the reasons for geographic separation between team members, you can now collaborate clearly and effectively to quickly resolve errors in QA, Staging, or Production.