Within the field of cognitive science, it has been asked: what constitutes a quality analogy? Psychologist Dedre Gentner has proposed the Structure-Mapping theory that in essence says that good analogies are made by aligning low-level elements of two situations or problems and then using these low-level alignments to build up "higher-order" alignments between the situations, and the higher up you are able to find alignments built from previous levels, the better the analogy becomes. We fail to make good analogies when we focus too much on the surface structure and not enough on the actions and events taking place. For instance, claiming that King Arthur is a lot like King Lear because they both are about Kings is not a good analogy because there is no alignment between their actions and events. Claming that King Arthur is a lot like Michael Corleone while not a fabulous analogy, is at least better as you can find relationships on which to build the analogy, such as that they were both leaders that came to power through an unexpected event (pulling sword from stone/killing police chief).
This theory relates to work done in education on the difference between expert and novice thinking. For example, novices and experts are shown a pair of physics problems each involving a "wedge" but involving different physical laws. When asked if the problems were similar, novices were likely to say, "yes, they both involve a wedge". The experts were likely to say, "no, they both have a wedge, but here I'd have to use Newton's second law, and in this one you're looking for the spring constant". The problem is that the novices focus on the surface similarity instead of the underlying principles involved and thus make a false analogy between the situations.
I think this same mistake is made when trying to fix bugs. We get too caught up in the "surface" features of the bug such as the visible effect on the system, and the place in the code where error is happening. One of the harder things to do is use that information to look for the deeper relationships, connecting the dots of the visible effects to nominate core underlying causes. Bug tracking systems only reenforce this notion by making symptoms prominent, with little or no place to track causes. This is understandable in the context of someone reporting a bug who wants to look for problems similar to theirs. However, when symptoms are used as the primary indexing attribute of bugs, it starts to conflate a variety of unrelated problems under a common heading. This can lead to both issues of reputation when a person's bugs keep getting reopened despite the fact that they fixed the issue completely and correctly but the bug happened to have a common symptom, and issues of disjointedness, where patches to fix symptoms are constantly applied rather than identifying and addressing an emergent pattern that points to a single underlying problematic component. Only by digging deeper into problems and creating those "higher-order" relationships can we eliminate these root problems that give us ongoing grief.
