Effective Communication to Developers for Quick Bug Fixing

It’s been about 10 years since I tasted the glory of being software developer. It’s all started when I was still in college building a small E-Learning project and here I am right know mainly focusing on SAP ABAP for a living.

Throughout those years, I have won many battles. I experienced the pain, the suffering but in the end the triumph. I’ve slayed many requirements and bugs too. So I know more or less how I prefer to work and perhaps represents how most of all software developers prefer to work.

When it comes to bugs, it is usually categorized to the severity or the impact it would have on the system. The higher the critical level, the quicker the bugs must be resolved. So yes, time is of the essence. In such a high pressure, an effective way of communication needs to be implemented. Wishing the developers to get their job done quickly needs to be complimented by the effective form of communication of informing the developers. If all we get is just “I found a bug here” or “I can’t do this/that”, it’s just like finding a key in the haystack. You won’t get results quickly by that clue. So here are the important points that need to be informed to the developers

The Critical Level

As I mentioned above, yes this element needs to be informed to the developers because bugs or issues can come several at the time. We developers are not superhuman computers, we can’t solve several issues or bugs at once. Hence, we need the critical level for prioritization.

The Simulation

Even though I said earlier we are not superhuman computers, we tend to think like one. Sometimes all we care about is input and output, especially in desperate times. So in order for the bugs or issues to be resolved quickly, better get to the point. Tell us or show us the simulation on how the issue or bug produced (the input) and how is the expected outcome from the input. In short, 3 things must be informed: what is the input, what is the actual outcome, and what is the expected outcome.

The Business Process

This part is additional information for developers. Surely in such a short notice this can not always be informed to the developers properly. But if time is on your side, this part is always useful. Sometimes by acknowledging the business process or how the user uses the system, we developers can even provide better solutions than the expected output. This part can also spark disagreements or discussions from developers so make sure the bug is not on a high critical level or there is still plenty of time to work on this.

So those are the essential points to inform the software developers effectively for quick issue/bug fix. Those tips are based on my experience and personally I find that useful and effective. Hopefully it can help anyone too when interacting with software developers.