Monday, October 6, 2008

Codeless Bug Fixing

Someone and I were having a conversation today, and at some point the following exchange occurred:

Him: "We should just get rid of oldScript entirely since newTool does the same thing."
Me: "But there are still bugs in newTool."
Him: "It's just that newTool counts things in a slightly different way."
Me: "Satisfactory explanation of the discrepancy counts as a fix."

The point here is that fixing bugs does not always require changing code.

After all, a bug is ultimately a difference between expected and actual (behavior, appearance, performance, experience, ). Resolving that difference is the point of fixing a bug. However, and this is the tricky part, there are two halves to the difference - the software and the user (person or system). Either side, or both, can be changed to fix the bug.

The myriad ways we can fix a bug include:
  • write, modify, or delete code to alter the behavior of the system
  • explain what's going on such that the user no longer perceives the behavior as unexpected
  • modify the configuration of one or more elements in or outside the system, resulting in modified system behavior or user experience
  • change the hardware or underlying components to produce a change in system behavior
  • some combination of the above
It's easy to look at a bug and then immediately look at the code. Sometimes, though, it's a better idea to consider the system as a whole and figure out where your fix really ought to be. There are, after all, several valid choices. The code is important, but sometimes your bug fix can be codeless.

No comments:

Post a Comment