The 1990's Called, They Want Their Bug Reporting Process Back

Software development has improved 100x since the internet was invented, but how people report bugs has not changed since the 1990s. Have you ever experienced this? An engineer picks up a ticket, and after some investigation, they determine that it works fine on their end, and they don't have sufficient information to reproduce the bug. They add a comment to the ticket, switch over to a different task, and wait for the bug reporter to supply them with more information. This cycle repeats several times, and each time there's new info in the ticket, the engineer has to remember where they left off and try to pick up the thread. Context switches like this are painful for engineers, and the typical bug-reporting process seems to be the poster child for this sort of hassle. The real life of a bug Imagine a fellow employee reports a login issue in the engineering Slack channel, and a couple of engineers drop everything to investigate. Despite their best efforts, they can't replicate the issue. They request more information such as the type of browser and device. Then they instruct the employee to try various troubleshooting steps like clearing the cache and refreshing the page. The async chats back and forth often consume an hour or more. Eventually, the engineering team has to schedule a debugging call with the employee to try to identify the issue on their computer. During the call, the employee shares their screen, and the engineers guide them on how to open the console and network tabs in dev tools to discern what's happening. Ultimately, the engineers see that there's a 401 error in the network tab, that says, "incorrect password." In essence, the problem wasn't that the login was broken, it was that the front end failed to bubble up the "incorrect password" error message and display it to the user. A simple front-end error that should have taken five minutes to identify and solve cost a couple of engineers their afternoon. Time for change Today's bug-reporting process remains archaic. Since the 1990s, the world has invented instant messaging like Slack, and video-calling like Zoom, and adopted remote work globally. Bug communication has gone digital. Bug tracking has moved from written files to Jira tickets. And yet, bug reporting is still filled with the pesky back-and-forth that wastes engineering time. We’ve all experienced the frustration of dealing with unclear bug reports that lack the necessary context to solve the issue. That's why a year ago, a few of us started imagining a better way. What if we could build a new tool that modernizes bug reporting and could solve the problem of unclear bug reports, reduce the need for back-and-forth communication, and save engineers' time and energy? And so, the idea for was born. A tool designed to make the bug-reporting process more productive and efficient. We wanted to create a solution that would help engineers solve technical bugs, not communication problems. Jam So, we set out to build a tool that would enable anyone, no matter their technical background, to capture rich contextual technical data about bugs, so that engineers could quickly identify and resolve issues. We wanted to create a tool that would make engineers' lives easier, while also helping the people who report issues to them be more effective too. As we developed and tested Jam early last year, we saw the potential it had to speed up the way our own team works. For example – take this Jam of a bug in our own code. Instead of needing to hop on a call to debug live, our engineers could see what the issue was, right from the bug report itself. We began to share Jam with other engineering teams, and we were really excited by the response. Ramp, T-Mobile, and Dell were among the early adopters of Jam and provided invaluable feedback that helped us shape the product. Iterating on their input, we're now proud to say Jam has over 14,000 users and counting. But our work is far from done. We know that the bug-reporting process can be a major source of frustration for engineers, and we're committed to changing that. If you're fed up with unclear bug reports, we invite you to give Jam a shot and let us know what you think. We're on a mission to build a better future for engineering and we need your feedback to make it happen. You can reach out to me personally at dani@jam.dev and join us on this journey.