Reporting Bugs in Software

As a developer, bug reports are part of my life. I give a machine instructions. I send those instructions out into the world. Users type with their butts. I get bug reports on how that doesn't always work.

Or, my users do perfectly reasonable things and certain combinations of those things have effects that I didn't predict or handle. So, I get bug reports.

Some of those bug reports consist of somebody screaming at me about what an idiot I am and how upset the user is without providing any actual information. Some of them provide some information but few specifics and, again, a lot of screaming. Some of them clearly describe the problem. If you didn't already know, those last ones are the ones most likely to get fixed. Not because they didn't say mean things to me, but simply because they gave me what I needed to find and fix the problem.

There are certain members of my beta test group whose reports get my immediate attention. When these people report something, I know it's real and I know they've put an effort into providing me with the straightest possible path to the bug and the subsequent fix. If you want to be on a developer's priority list, consider following these guidelines for reporting bugs.

Things to include

 

Subject 

A brief description of the bug. The subject should allow the developer to quickly determine what area of the software is affected. This allows them to quickly assign the bug to the correct team member, and to group related bugs together. It also helps them to check out related issues and previously fixed bugs that might be affected by current work.
A useful subject line: Crash when loading invoice form
A not-so-useful subject line: CRASH!!!!

 

Version

As much information as you can provide about which version of the software in which you saw the bug. This information is often available in the About box for the software.
Example: Microsoft Word 2010 (14.0.6024.1000) SP1 MSO (14.0.6112.5000) (32 bit) as part of Microsoft Office Professional Plus 2010

 

Environment

Provide information about which version of which operating system you are using. Depending on the software about which you are reporting, you may also want to include information about your graphics card and driver, amount of RAM, etc.

 

Description

A complete description of the bug. This should include as much detail as you can give as to what you were doing when the problem occurred. If the software has modes, tell the developers which mode you were in. If the problem occurred when you saved, tell the developers whether you used a keystroke like Ctrl-S, or clicked on a toolbar button, or selected Save from a dropdown menu. The developer may be dealing with millions of lines of code. All the things that you take for granted because you always do it a particular way are critical in helping a developer track down which part of their code is causing the trouble.
A useful description: I was adding a new Invoice. I filled out the main Invoice information, then clicked in the Line Items table to add a new item. I filled out the Line Item fields and clicked back to the Invoice Date to make a change. My new Line Item disappeared.
A not-so-useful description: I tried to add a new line item and it disappeared.

 

Steps to Reproduce

Bug fixing gets a lot harder when you can't make it happen and you can't test whether it's gone. If you can give the developer exact steps they can follow to reproduce your problem, your issue will get fixed a lot faster.

Useful steps to reproduce:
Open any document
Click the Page Layout tab
Select all the text by pressing Ctrl-A
Click the Columns button on the ribbon
Click Three
Crash

Not-so-useful steps to reproduce:
Select some text
Set it to use three columns
Crash

Things to Not Include

As developers, we understand that bugs can be frustrating, upsetting, and even scary. We don't like them either. However, if you want to rant, you should talk to Customer Service. Development's job is to identify and fix the problem. Anything that doesn't help us do that is just a distraction. Along those lines, there are some things you want to leave out of bug reports.

 

Jokes

We appreciate that you want to soften the blow and humor is a wonderful thing, but a developer deep in bug reports and source code is in a very literal place. It may take them three readings to figure out that you are joking and, if your joke implies a problem, they may have spent an hour trying to track it down before they figure out that you're kidding.  Dry-as-dust technical information is the way to go.

 

Emotional Content, Emphasis, and Essays

We understand that the bug you are reporting may have caused you significant frustration, wasted time, and worry. We're really sorry about that. We didn't write it that way on purpose to upset you. We want to fix it so it doesn't upset you or anyone else ever again. Wading through three paragraphs typed in all capital letters about how stupid we are and how much of your time we wasted just makes it harder for us to dig the actual problem out of what you are saying. We get that you want to vent to somebody but, if you want your bug fixed, the developers might not be your best choice of outlet.

Most of the time, developers don't need to be convinced to fix a bug. We want to fix our bugs. When management or suchlike prevents us from fixing our bugs, we get very frustrated and gnaw on things. We are likely to understand why your bug is a problem simply by reading the description. We don't need an essay about why it's a problem if the program crashes when you try to put text in columns to understand why we should fix that. It's just more stuff we have to dig through to find the actual description of the bug.

 

Justifications

Either the bug happens, or it doesn't. The bug doesn't know or care that you have worked with fifteen other packages for the past thirty years and know all about software. Maybe you do, and maybe you don't. It doesn't change whether we can make the bug happen using the steps you provided. Again, we don't fix bugs based on the perceived credentials of the reporter. The only credential that moves somebody in my beta group up my attention list is that they have a history of being a reliable and thorough bug reporter.

In Summary

When reporting an issue to a developer, efficiency is everything. If it doesn't help them identify the bug, leave it out. If it does, put it in,

CSS and the War on Tables

Ok, I'm just gonna come right out and say it: I still use tables.

Not for everything, mind you. There are certainly places where divs work better, and I use them. But I've about had it with the hysterical shrieking about how you must use divs for everything, even if they don't work as well, or the webpage police will haul you off to webpage prison where you will do hard webpage time. Seriously, folks, enough. You can have more than one tool in the toolbox.

CSS has a variety of great and useful tools of which I take advantage on a daily basis. That said, I'm tired of pretending that either of the S's stands for "structure." I'm also tired of pretending that sacrificing two chickens and an Amiga to the God of Floats and Margins while praying that nothing moves by so much as a pixel is a reasonable substitute for the tremendously useful balance between rigidity and elasticity that tables provide.

Separating content from presentation is a great idea. I'm all for it. Structure is neither. It's not that I can't do it with divs. I can. I have. I'm not doing it any more. To do what I need structure-wise with divs, I find that I (and others also from the examples they post) end up building the exact same structure with divs that I used to build with table elements. Which would be fine except that it takes at least three times longer and the result is a fragile animal that lets sections be pushed out of position, breaks if the size of the content changes too much, and requires jumping through all sorts of hoops to have two things next to each other stay the same height. 

I tried drinking the Kool-Aid. I really did. But I sincerely believe that this is one of those cases where the Emperor needs to tell his tailors to settle the f*** down.

My Computer. It Is Not a Phone. (Windows 8)

I've been looking at the advance screenshots of Windows 8, and so far my main reaction is: Why?

This style of interface is fine on my phone. My phone is small, has a touchscreen, and I don't do much in the way of real work on it. My PC, on the other hand, has a dual-monitor setup, does not have a touchscreen, and I need to do complicated graphics work and software development in multiple languages and IDEs. So, why does it need to have the same user interface as my phone? Why do I need to page through tiles when I'm not swiping a screen with my finger?  I have a mouse and a keyboard and a whole lot of screen real estate. Why would I choose this paradigm? Why?!

It was bad enough when the monitor manufacturers decided that all I do at work is watch movies. Now, the Windows 8 desktop designers seem to have also decided that I don't actually work at work.

Well guess what, folks. I use fully-fledged applications, not apps. I use all ten fingers on a physical hardware keyboard; I don't peck out my code one letter at a time on a soft keyboard with overly helpful autocomplete. I do more with my mouse than drag prefab objects and poke a limited set of clickables. In other words, I WORK AT WORK!

Please, for the love of Turing, please don't turn my PC into a smartphone. I have work to do.