4 minute read
What do developers in HackerNews think about existing Bug Trackers

Back in the 90s and 2000s, software developers were notorious for chanting, “It’s not a bug, it’s a feature” whenever there was a glitch reported in their software design. We’ve come a long way since then. GNATS came out as the world’s first stable bug tracker in 1992, and bug 

tracking has now become a routine process for every software developer and distributor. Bug tracking and reporting software, too, has evolved over time. 

Change is inevitable, isn’t it? Unfortunately, that has not been the case in the bug tracking world. Enterprises and companies, big and small, keep working with legacy bug trackers. These bug trackers are bulky, complex, and slow. What’s more, they slow down software development. In an age where the speed of moving is supercritical, many startups remain oblivious that their bug tracking system is slowing them down. 

The tipping point is coming. 

Grasping the depth of the problem 

Let us take the case of a startup a decade ago. Legacy bug tracking tools were clunky and had several developers reopen bugs over days and weeks. Faced with resource crunch, everyone in the start-up had to sift through data, find bugs, and fix whatever they would find on the go. Software development cycles often came to a grinding halt, and development cycles had to be inevitably extended. The alternate scenario was extended working hours for multiple developers and an increase in late-night cab services for those developers. 

Is the situation now any different? 

Cut to 2021. Improving quality pales in comparison to creating new features. Several enterprises are making strides in the automation space, which also necessitates maintenance. A job caused by regression means that when one bug is fixed, another one appears somewhere else. It still takes time, and those late-night cabs still ply sleep-deprived developers. Existing bug tracking systems, especially those that have been used for years now, don’t seem to help. 

And this is just the tip of the iceberg. We cannot stress enough the importance of a good Bug Tracker. The case study also highlights how essential the coordination between the developing and testing team is. Thus, a developer’s opinion in choosing a bug tracking software is indispensable. 

What do the developers in HackerNews think of existing Bug Trackers? 

Here’s a list of existing bug trackers and what HackerNews developers think of them in a nutshell: 

1. Ditz 

  • A simple, lightweight distributed issue tracker designed to work with distributed version control systems like Git, Mercurial, and Bazaar.
  • The directory of bugs is stored on a disk and can be kept in version control like project code is. 
  • Additionally, the UI for updating and creating the database storing files is console-based. 
  • The files are written in an editable and line-based format. 

2. PyDitz 

  • PyDitz is the Pythonic drop-in replacement for Ditz. If that makes you think it follows the original to a T, you will be pleasantly surprised. 
  • A neat auto-completion feature on issue, release, and command names. PyDitz maintains a cache of bugs that occurred previously, and therefore, you don’t have to parse all YAML files while executing every command. This improves your resolving speed in case of frequently occurring bugs. 
  • Python programs and PyDitz’s database engine can help bug database migration across bug trackers. 

3. Jira 

  • Jira is the market leader in customizing itself to any company’s workflow; however, its speed is a huge dampener. 
  • Deployment across all platforms- web, desktop, cloud, SaaS, on-Prem, Web-based, and mobile is handy. On-Prem deployment is subject to a pricey Data Center license, which is problematic. 
  • Notifications in Jira can be highly customized, even setting up filters to automatically move to */automated/Jira directories. 
  • An issue without description can be created and concealed. This is annoying since testers don’t understand why it was raised in the first place. 

4. Zoho Desk 

  • Zoho is now head-to-head with Jira. Its most famous USP is its escalations management feature, which other bug trackers don’t offer yet. 
  • Its extensive support and training options. 

5. Bugasura 

  • Developers feel that the current bug trackers are generic and workflow-oriented than bug closure. Bugasura brings a welcome change with faster closing before release. ‘Nudges’ are bug resolution reminders at various points of the bug lifecycle. Developers want this tweaked so that they are notified only for tasks that need to be resolved in real-time- a client call or server failing. Otherwise, it becomes a hindrance since it constantly competes for the developer’s attention. 
  • Threshold of bug tracking on every page <100ms. 

After a careful analysis of the aspects that work for bug trackers and the ones that cause the most heartbreak, here are the key takeaways from the platform. 

Key Takeaways: 

  • Exiting bug trackers are user-friendly but give away their implementation. Require too much effort to set up the environment initially. Developers do not want their front-end or testing teams to have to do so much solely for ticketing. For example, the Ruby implementation of Ditz needs the installation of the package ‘gem,’ the Python implementation necessitates ‘pip install PyDitz,’ while Radicle necessitates a complete overhaul of the existing track. 
  • Given a choice, developers would happily adopt Bugasura in place of Jira. The most well-received feature is the bug tracking performance of Bugasura. In their words, most SaaS require sweeping developments in this area. 
  • Future work on bug trackers should make it executable, Git-based, local(offline), redundant, and faster. 
  • Making the bug tracker serverless is advantageous since the user can make changes offline, combine their commits, prevent disruption of the bug tracker and low latency. 

The multitude of modifications, appreciation for specific metrics, and the downers for existing bug tracking software show the amount of work, resources, time that organizations need to invest in this area. This is time that is critical for improving the speed of development, increasing efficiency and promoting a healthier quality of life among engineers.