Analogy Breakdown Anti Pattern

AntiPattern Name: Analogy Breakdown

Also Known As: Adding Complexity through Analogy

Most Frequent Scale: Application

Type: Development Architectural Management

Root Causes: Sloth

Unbalanced Forces: Management of Complexity

Problem: The software design process suffers from a lack of precision; as it is continually being characterized through analogy. Justifications and architectural decisions may be based upon constraints imposed by an analogy instead of the problem at hand.

Example(s):' Usually starts off with 'it's like that episode from Star Trek.........'.

Here is a recursive example 'This anti-pattern is akin to the current abuse of applying the principles of physics to the business of living e.g. the Tao of (insert here)'.

Anecdotal Evidence: Any typical xml-dev debate about namespaces and URI's.

Refactored Solution: Architects should employ strong software modelling techniques and strive for clear documentation for generic design justifications.

Resulting Context: Design justifications are poorly documented, resulting in 'Why did we do this... ' situations. Software may reflect an elegant analogy within some process, that simply doesn't satisfy the applications requirements when scaled or changed imparting a friable nature to your software design.

In addition, this loss of precision will require a continual reiteration and reformulation of design principles at each stage of your applications development, wasting valuable development time and introducing variation due to interpretation of specification.

Applicability to Other Viewpoints and Scales: As powerful as analogies are, Managers should 'flag' overusage of analogy by 'reining in' developers and architects with simple 'write it down and does it make sense' tactics.

Author: James Fuller ( jim.fuller@ruminate.co.uk) / www.ruminate.co.uk

Interesting. My girlfriend just asked me to stop trying to make analogies when I talk about my code to her.

But did she really mean she wanted you to stop talking about your code to her?

See also: StopUsingMetaphors, MetaphorSmackdown, SystemMetaphor and in particular ArgumentByAnalogy

Analogies are a sure-fire way to derail a thread/topic. A solution to this is, when in a meeting, instantly chop off analogies and get back to the subject at hand. A similar concept is when people initially discuss a problem and someone spouts off class taxonomies (or other implementation details) before clear analysis has been done.

An increasingly common Analogy Breakdown, but not in software design, these days: treating copyrights, patents, etc. as property rights, resulting in the term "intellectual property" and referring to infringement (and also, quite often, to fair use) as "theft". Choice of poor analogies is a huge problem in itself, as well as overextending one that wasn't necessarily poor from the outset.

CategoryAntiPattern CategoryArchitectureAntiPattern