Analogy

Analogy isn't really about ideas, but describing a system - or a problem - in terms of something else can often help you understand it better.



To come with an analog [http://en.wikipedia.org/wiki/Analogy] you follow a similar process to come up with a model when designing databases. Pick off the characteristics which define the thing in the current context and, instead of modelling this in the abstract you find something which shares the same characteristics.

Systems are complex. Describing complex systems becomes confusing, so the role of an analogy is to simplify but still reflect the important characteristics, given the context. Often, people get confused because ever one is inventing and misusing words so the analog must be understandable by everyone.

In debugging, the analogy differs from the analogies used in creating models or defining projects in that they'll be much closer to the real world. This is just a fact of  when debugging happens and everyone's state of mind; no-one has time for stupid imaginitive analogies when something has broken.

I keep saying that the analogy describes the system in the important characteristics, given the context. In you're modelling user traffic and you find that some users cause the system to fall over, describing those users in terms of the colour of their shirt isn't going to get you far. A less moronic but still useless characteristic would be how fast they click links on the webpages, which might lead to an analogy of triggers clicking at varying speeds but doesn't describe what really matters.

A good analogy will entirely replace the real world description. Again, picking off the main characteristics and working in terms of only those will lead you to think in the terms that matter

Analogy allows you to describe the problem in terms of a familiar system. For example, instead of describing a complex workflow in abstract database terms, use familiar concepts of paper documents.