Developer Talk - Bug Reports
     Hello everyone, so this is going to be a new little segment about developer-related issues, common questions, and just general tips and tricks for upcoming developers.

    This concept of software errors, later dubbed a "bug," has been around since the 19th century, which is incredible to think about. Of course, back then it was incredibly more frustrating than in today's world, but today, as I'm sure was true back then, we have various issues with bug reports. This issue isn't really with how they're handled, but more of how they're reported, which really stems back to people that know about technology, and those that do not. It's incredibly easy to trace down a bug when another developer submits a report, and knows the lingo of the developer world, but then you have your "average joe," which may create a report as such:

"This feature doesn't work. I've tried everything, and it just doesn't work"

Now, while it's great to have someone using the software you've created, this form of a report doesn't help you out at all. In fact, it actually just causes more work in the sense that you now have to respond asking for more information, and then wait on the consumer to end-user to respond.

   What can we do to prevent this? The perfect solution is to create a simple set of guidelines for bug reports. Now, I'm not telling you to spend hours writing out a novel, which ultimately nobody will review in the first place, but rather the basics you require to trace a software bug down in a reasonable amount of time. We do better when we're spending our time efficiently, and having informative bug reports is important in time management.

  In closing, bug report guidelines will save you not only headaches, but also time in the end, and they don't have to be the length of a copyright header, let alone a novel. If you'd like an example, here's TNE's report format , which is straightforward and to the point.


As always, thanks for your time,
   Daniel "creatorfromhell" Vidmar