On bug reports
There’s an old joke about a Manager, an Engineer and a Software Developer: they’re in a car and the brakes fail as they go down a mountain road. They miraculously come to a standstill, but now they’re stuck, and Somebody Should Do Something ™. The Manager suggests they make a Plan, define Goals & Measurable Objectives in order to solve the Critical Problem. The Engineer has his tools with him, so he suggests he take look at the problem and fix it. The Software Developer, of course, is not convinced and suggests they push the car up hill to see if the problem will manifest itself again …
You can probably find a bunch of different versions of this on the web, but the punch line is always the same: the developer wants to be able to reproduce the bug. Not just to verify its existence (although it wouldn’t be the first time a user reported a critical data loss bug after having pressed the delete button..), but also to have a place to start the bug hunt. Software systems are complex. We have enough layers of abstraction built on top of a bunch of transistors to make Shrek jealous. Something as seemingly simple as displaying a bit of text on a screen is so complex that it can no longer be fully understood by a single person.
Being able to reproduce a bug is the only way to resolve ambiguity. When it isn’t possible to describe all the steps that led to the bug, then a thorough description of the problem is the next best thing. Think screenshots, explanations of the expected result, and answers to all of the usual “Which”-questions (Version, OS, Environment, Lunar Phase, ..).
Debugging is hard (and fun). Vague bug reports like “the application is broken” rather make me want to tie a team of horses to your limbs and decapitate your bloody remains educate you on the virtues of well-written bug reports.
Now .. let me see if I can fix this “broken” application .. sigh.
— Elric