In software development and support, a huge part of the iterative process is the feedback loop. It’s important to remember though that problems (bugs) and solutions are also skewed by perception and experience.

Bugs aren’t always software–sometimes they’re process, workflow, and people.

In a recent post by Doug Bradbury, he relays how handling bugs can be narrowed down to three steps. I’d like to focus on the first and last of those steps, acknowledge and amend, a bit.

Acknowledge

Always assume that a reported problem is in fact a bug. Remember that the person reporting a bug has no idea what’s wrong. They assume that they are the ones doing something wrong. A user has to reach a really high level of frustration before they get up the nerve to report a problem.

Hearing, “You are right, that doesn’t seem to be working properly,” lifts a huge weight off the user who was starting to think they were going crazy. I believe it’s also important to remember that while acknowledging, you must not only acknowledge the bug or issue, but also the situation that the user is facing–empathizing with WHY this is a concern for them.

As masters of our own systems, developers tend to forget that users inherently lack the insider information of why a feature works a certain way or how edge cases can occur (this is why having external testers is important who don’t glance over issues that you mentally overlook).

That insider information mentioned a moment ago leads us to amend.

Amend

Defects are highly offensive in the crafter’s work, and are addressed immediately and thoroughly.

There’s times that the defect isn’t in the design or the code, but in more subtle things such as workflow, training, or user experience. User personas can help design flows and features in a system, but–especially on the web–most web applications don’t have hard start and stop points.

For example, in a prior project in the early 2000s, my firm designed an online record keeping system for a mid-sized firm to store, catalog, and retrieve everything from electronic documents to audio records from interviews and discussions (this predates a lot of eDiscovery and modern document management systems we have these days). The system was well received… until a new team started a year later and bug reports started coming in left and right.

Did the system suddenly stop working? No. The new team had a different workflow and didn’t know what potholes to work around.

Where did the problem lie then? To amend the issue requires understanding the problem and driving decisions off of data.

Part fell on my team for not finding those edge cases in our tests and documentation and, Part fell on the prior team for working around them rather reporting them as defects when their internal workflow changed. The solution?

We quickly acknowledged the issues and not only amended the issue with code, but also by working with the customer to formalize training, documentation, and an onboarding plan for new employees to the company so that the insider information wasn’t lost each time the team cycled through.