This week, Spotify released a statement calling out Apple for anti-competitive behavior. Apple responded. The discussion that surrounded the exchange was centered on interpretations of what anti-competitive behavior is and why Apple is or is not engaging in it. There’s no clear answer. This is especially true because anti-competitive behavior is relative, not absolute. Different people will have different thresholds for what constitutes as acceptable. Many compared the Apple/Spotify situation to related situations: Microsoft’s anti-trust case, Kindle’s iOS app, and even physical storefronts.
There’s a problem with using analogies. Depending on the example used, analogies can either help or hurt Spotify’s case. This isn’t a problem in itself: using an apt analogy can help others view the problem in a way they hadn’t considered before. The problem occurs when the analogies used are bad; in other words, when they aren’t representative of the original situation. This is when choosing an analogy based on a preexisting opinion can be harmful; by choosing analogies not for their merit but for their contribution for our argument, we distort the perception of the situation.
Here’s an analogy I saw used to argue for Apple:
Walmart owns their storefront, so they can choose not to sell something if it violates their terms of service. One of the terms of being on the Apple Store is to use their secure payment service for any in-app purchases. Apple can choose to set their terms how they want, and if consumers don’t like them, they can use another phone (just like Walmart shoppers can go to another store).
And another for Spotify:
Apple’s App Store is like a mall. Apple Music is a store in the mall, and so is Spotify. The App Store (the mall owner) is charging a fee to Spotify (one of the stores) but not Apple Music (another one of the stores). Therefore, they’re using their position as the marketplace owner to decrease Spotify’s ability to compete with their other products.
These are both rough approximations to the situation that argue different things. The key here is that these approximations are rough. They don’t represent the situation fully. They leave out details. Both examples highlight aspects of the situation that support heir argument and use a real world example as collateral. The first example doesn’t mention the fact that Apple owns both the storefront and a competing product in that storefront that isn’t subject to the same rules. In the second, it isn’t mentioned that some malls make money by revenue sharing - taking a cut of sales from stores in their mall - while for free apps with external payment systems, Apple gets nothing. The situation is much more nuanced than these analogies would make it seem. As standalone arguments, these obscure the problem and can lead to uninformed decisions.
A bad analogy is like a burrito: it doesn’t work.
As both a tutor and a student, analogies can be really helpful. For an analogy to be good, it should have two qualities: it should accurately represent the situation it’s trying to describe and it should be simple. A lasting memory from my OOP course at uWaterloo is of my professor beginning the class by holding a baseball. “Exceptions are like baseballs. If I throw it to you,” he said while throwing the ball to someone in the first row, “you have to catch it or else it’ll hit you.” From that point forward, baseballs formed the basis of my mental model for exceptions in C++; not catching exceptions (baseballs) will result in your program crashing (you getting hit). It’s easy to remember. It fits well with C++’s catch keyword for handling exceptions. It allows for a basic understanding of how an exception behaves without needing to understand the details. In this case, presenting the analogy as a simplification of a more complicated, abstract mechanism made it easier to grasp initially. Sometimes, hiding details early on can be helpful (essential, even) for early understanding.
This is a double edged sword. Analogies are appealing because they’re simpler than the situation they approximate. As a result, there must be less information in the analogy than there is in the original situation. This can be good for initial understanding but it can hide important details. In some situations, a bad analogy can prevent understanding. In 2006, Senator Ted Stevens was ridiculed for referring to the internet as a “series of tubes”. In the same speech, he refers to the internet as a freeway and compares network congestion to a traffic jam. The analogy fails the most important usability test: it isn’t accurate. The situations are somewhat similar on the surface but the analogy breaks down when comparing the complexity of the internet to a highway. The arguments Stevens makes wouldn’t have been bad if he was actually talking about a highway. His misunderstanding of the underlying concept due to the bad analogy he used took away from his points instead of adding to them. Bad analogies lead to bad arguments.
This can be dangerous when the arguments are important.
Let’s go back to Spotify vs. Apple. Regardless of your position, this is an important argument to have. If Apple is justified in using their position as a phone vendor to charge fees to non-Apple apps, then that has huge implications for any company trying to compete with Apple. If customers are charged 30% more for a similar product, which one are they going to choose? That alone could be enough to price Spotify out. On the other hand, if they aren’t justified, then what should be done to stop them? Does legislation step in and limit the rate Apple charges third party apps, or do they break up Apple’s services into separate companies?
At the end of the day, it’s a legislative problem. It depends on the interpretation of anti-competitive law in the US, but it also depends on how well the people making these rulings understand the whole situation. With Senator Stevens, a bad analogy derailed his understanding of the how the internet works. I don’t bring that up to pick on Stevens; rather, it’s to highlight the fact that the people that make decisions are not going to have the technical background to understand all the details. They’re going to rely on analogies to prop up their understanding.
It’s important that we ensure they’re using the right ones.