Thursday, March 7, 2013
Bugs: A FEARful Approach
We can request changes to the way the product behaves, to remove pieces of functionality that have lost their utility, to merge pieces of functionality that perform similar roles, to consider new functionality or utilise new or better libraries..
We can constructively criticise process or lack of process, suggest ideas for improving the product for internal customers such as support, ways in which our support ticketing system could be more efficient, bottlenecks in the way we develop software, reasons that projects overrun, ideas about why bugs weren't found in testing...
I could go on (and believe me I do go on).
Most often when an issue is found a ticket will be raised. But I report some in email or project briefings or management meetings or into the IT ticketing system or by commenting into a document I'm proof-reading or into our wiki or in IM or verbally or wherever seems like a productive and efficient route to fix or raise visibility of the issue that I'm interested in at that time. They might be a mention-in-passing or something more formal. They should always be clear about the motivation for reporting.
Particularly in the software, even impossible-to-repro behaviour can be logged with the expectation of it being marked worksforme (which we often do eagerly in triage) but with as much relevant data as possible (and commentary on the degree to which the data is believed relevant) so that subsequent searches will hit it, and the hope that later reports will enable us to characterise the problem.
The goal here isn't to annoy anyone, or to raise anyone's bug count or provide ass-cover when something goes wrong down the line. The goal is to improve the software and to improve our production of the software and to improve our understanding and knowledge of the software. This shouldn't be a scary notion, so it's unfortunate that the acronym I prefer is FEAR: File 'Em All, Respectfully.