Since my previous post on suggestions around best way to explain APIs to a non-technical audience, I gave an in-company talk on upcoming features on the technology I am currently working with (MuleSoft).
The great replies received in the last post inspired me and I already started applying some of the suggestions.
This brings me back to the fact that the easiest way to connect with your audience and have them easily understand concepts that otherwise would seem difficult to grasp is to use analogies with which they can easily relate. The discussion becomes more appealing and at the same time easier to follow.
The most recent analogy I read about and also used, is related to explaining how streaming consumption works.
There are two main challenges when consuming a stream:
- it can only be read once
- it cannot be read in parallel
Think of a pint of beer, each sip you take is one sip you cannot take again. Similarly, if two people use two straws to sip from the same pint, none of them will ever drink the full pint.
Do you have preferred analogies to explain complex IT concepts? Curious to hear your thoughts around this! :-)
Top comments (26)
I like to talk about software development a bit like gardening, in that you have some control over what happens, but if you go away and come back, your plants will have grown out in all sorts of weird ways. And even if you planted all those plants yourself, you don't really know everything about the state of the garden.
Software is really complicated, like biology. Even if a system is technically somewhat deterministic, for all intents and purposes, it's pretty random. There are a lot of things we can do, like watering regularly, paying attention to the size of our containers, buy the right dirt, hire more gardeners, etc. But there is no such thing as a garden you can just walk away from because it's "finished"
I know from experience: I let a cactus die from neglect. Cactuses are supposed to be, like, invincible.
Reading your reply, Ben! My conclusion: Software Development is like gardening, so many similarities there, I'll spread the word around. Hope you won't mind me quoting you when the opportunity comes.
Regarding your cactus: it takes a great deal of courage to admit you managed to let it die. Indeed, this is seen as something almost impossible! :)
🌵 😭
😊
You know, the more I think about it, the more it makes sense.
At first, I thought, "well, if nobody touches a garden, it grows by itself, but software doesn't." But then I realized that, if you don't touch code for a while, everything else grows around it. Libraries, frameworks, operating systems, etc.. Also, memories of how it was built fade. The result is the same: software, like a garden, becomes in desperate need of maintenance over time, regardless if anyone changes it or not.
This is a great analogy. Thank you for sharing!!
Before I started web development, this analogy really helped me understand what APIs are.
Hi! Wonderful analogy, keep them coming! :)
A comment turned into video: videos.mulesoft.com/watch/Le2QkL3l...
Cool!
Oh, another one. This one helps me understand the difference between margin and padding.
Hehe, good one. During Swedish winters, margin is extremely high, ie: wearing thick clothes for cold weather!
Sorry, I made a mistake and confused the two 🤐. updated
Here's my analogy for authentication vs authorization:
Thanks, Andy! Hope you won't mind me saying, I believe in this example there's a thin line on whether showing your driver's license to a police officer for verification could be seen as authorization or authentication. You could still see it as an authorization check on whether you are allowed to drive the car or not. What are your thoughts on this?
Hmm, good points. Definitely don't mind :)
How about:
Andy, this is close, but not quite right, I believe. You should only open the cookie jar after you confirm your identity somehow :-)
This analogy has helped me to understand the importance of programming to an interface. It presumes that technology advances more quickly than the domain in which the problem that we are trying to solve lies.
Suppose Jack and Jill each own a grocery store. When their stores opened a few years ago, Jack saw cash as the present and future de facto standard in payments. As a result, the rest of his system assumed cash as the payment method. Jill was slightly more open-minded and still wanted to be able to accept cheques. This meant that the parts of her system connected directly with payments had to be more generic than Jack’s – they were concerned only with the transaction amount. As long as the payment was valid, the method was irrelevant.
Fast forward a few years and Jack and Jill start noticing people asking if they can pay by card. Some would-be customers have to buy their groceries elsewhere because they've stopped carrying cash altogether. Both store owners decide that in order to stay in business, they need to start accepting card payments. Jack installs a card machine alongside his cash register but in order to integrate it, he has to completely redesign the rest of his system to work with cash and card payments. On the other hand, Jill just has to install the card machine and she's up and running. The rest of her system isn't concerned with the implementation of accepting payments. Jill takes the lion's share of the area's grocery business while Jack is busy redesigning and implementing his new system.
The moral of the story: to future-proof our code and follow the principle of programming to an interface, we should focus on what we are doing and not how we are doing it. (This analogy could be extended to other coding principles, loose coupling being an obvious example.)
Blair, thanks! To summarize, you mean that by going for a more generic way of payments (ie an interface), it was easier to add support for other payment methods later on. In OOP terms: a class implementing a interface.
Exactly, Ana. Apologies for the verbosity of my comment, thank you for your summary.
No problem, Blair! It was a good read! Thanks for your post reply! 🙂
I have to admit, when I was but a young n00blet in want of skills, I hated them xD
People were like "OOP ... yeah... an aggregation is like a car... and yes, inheritance is like animals"
Then I looked into production code with views, controllers, singletons, factories, decorators, managers, components etc. and didn't feel any wiser.
I also could tell that most non-technical people would take analogies literally. And why wouldn't they? The only right analogy would be a Turing machine, which requires as much insight as the original problem :D
It's ok to disagree on the fact that analogies help us understand complex concepts. We're all different and have our own preferred approach on best way to learn. As probably already concluded from the article: I'm on the side of people in favor of analogies :-).
Programming in general: Imagine you have a 5 year old. And you can teach him/her exactly what decisions to make for all kinds of situations, and the kid goes on making the right decisions each time, for months.
Until the kid confronts a decision you didn't anticipate in your teaching. And then all hell breaks loose. Ends with a frustrated crying breakdown.
Interesting one, at the same time I strongly believe that a 5 year old should also be encouraged to explore and learn things by themselves in order to develop their curiosity and be confident to go outside their comfort zone. In programming terms this could translate to AI (maybe?): learning from previous events and stored data :-)
You'll love this site then:
sidewaysdictionary.com
Thank you! You are so right, "love" is the right word! This is awesome! :-)
Authentication vs Authorization:
dev.to/ovidiu141/best-analogy-for-...