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.