Analogies are often used when building or discussing the architecture and design of a system. I think there are two main benefits to this.
The first is very obvious. Using an analogy allows one person to explain part of an unknown domain of knowledge to another person, by mapping portions of the unknown domain to matching portions of a domain known by both people. It is a great way of getting someone to understand something that seems complex, but is really a lot like something else they already know.
The other benefit is not quite as obvious and, more importantly, does not necessarily require a second person! When developing a new system, the target domain is rarely understood fully by any of the developers. In this case, analogies can be very useful for exploring the domain. You can start by mapping known attributes of the target domain to a common knowledge domain. Then, look for closely related (but unmapped) attributes in the common knowledge domain and attempt to find analogues for those attributes in the target domain. Even when this practice does not work, it is useful, since you might realize your entire analogy is weak or awkwardly constructed. A truly fitting analogy can provide deeper insight into your target domain.
Adam Platt is a technologist with more than a decade of experience across the full stack. His passion for technology and penchant for rendering complex technical ideas into simple terms have made him an in-demand speaker. His resume includes BriForum, the PowerShell Summit, teaching engagements and more.
He is one of the 10 types of people who understand binary and he can solve a Rubik’s Cube.
Adam Platt is a technologist with more than a decade of experience across the full stack. His passion for technology and penchant for rendering complex technical ideas into simple terms have made him an in-demand speaker. His resume includes BriForum, the PowerShell Summit, teaching engagements and more.
He is one of the 10 types of people who understand binary and he can solve a Rubik’s Cube.