Many To Many Needs Advocacy
By now, we have proven to ourselves that Many To Many Has Utility. We’ve demonstrated a need for Many To Many techniques to externalize our thoughts, because our thought categorizations are often multi-linked rather than hierarchical.
And yet at the same time, we’ve also proven to ourselves that Many To Many Is Misunderstood. We’ve shown that the influence of our physical world, which is hierarchical, often spurs us to try to represent our thoughts in hierarchical structures. We are often dissatisfied with the results, and yet we can’t easily move beyond the frustration.
What can we conclude of this?
It’s definitely true that hierarchical frustrations are commonplace. One only needs to visit an unfamiliar grocery store and look for vegetable oil to find an example. Is vegetable oil a cooking oil, to be stored near the flour and sugar? Or is it a salad oil, to be stored near the vinegar? Should vegetable oil be stored near olive oil, or in a separate aisle? When you are rushing to the grocery store at the last minute to prepare for impending dinner visitors, these can be frustrating questions. And yet, there is not a way around them, as a grocery store aisle is rooted in the physical world, and thus hierarchical. (A grocery store could split their vegetable oil batches into two locations, but this would lead to the same maintenance challenges that we saw with the library card catalog in Many To Many Is Not Physical.)
To break this down – when visiting our hypothetical grocery store, there is an expectation that vegetable oil should be where we expect it. If we need it for a baking recipe, it should be in the baking aisle. If we need it for salad dressing, it should be alongside the vinegar. These competing expectations don’t make sense in a hierarchical sense, but they exist anyway. And when our expectations are not met, we get frustrated.
It is commonplace to have non-hierarchical thoughts in our mind and expect them to be reflected externally. It is also true that these expectations cannot always be met – grocery stores cannot, in this example, be expected to split their stocks to meet the contextual expectation of every customer. But the reason they cannot be expected to do this is because they are rooted in the physical world, which is by definition hierarchical. We accept this limitation, we accept the frustration, and learn to tolerate it.
But what of the non-physical world?
Let’s think back to our card catalog example. A card catalog seemingly represents a many-to-many relationship between library books, and the ways in which a customer might search for a book. And yet, we’ve shown that this is only an illusion. The card catalog is not actually one representation of a book stored in multiple places – it is multiple copies of the book’s representation, stored in multiple places in the catalog. And since there are multiple copies, this invites all the struggles and errors that come along with keeping the copies in synchronization.
But let’s take a closer look at what is actually required when keeping these representations in sync:
- As often as is reasonable, we must cycle through all the cards in the catalog, and make sure the books still exist and are in the right place.
- As often as possible, we must cycle through all the books in the library, and make sure they all have properly categorized cards.
These are both examples of highly repetitive, high-maintenance, easily defined tasks. In other words, perfect for software.
In fact, these routines are exactly how many-to-many relationships are represented in computer software. Software serves as the role of our librarians, instantly and continually doing all the checking to keep a many-to-many representation perfectly in sync. It’s as if you look up a library book in a card catalog by subject, but with the book then instantly appearing in your hand.
And we are used to dealing with many-to-many relationships all the time in the non-physical world. When browsing for a product on an ecommerce website, you can find the product you are interested in whether you are searching by price, by color, or by size. When searching for a book on amazon.com, you can easily find it by subject, by author, or by title. Online, we experience far less of the frustration we might feel in the grocery store salad dressing aisle when we realize that the store believes we’re actually looking for cooking oil.
And yet – even in the non-physical world, the hierarchical model creeps in where it shouldn’t. A perfect example is todo list software. Let’s look at this screenshot of this highly-used, but unnamed piece of productivity software:
There’s a lot that is good about this software – you can subcategorize your items. You can even specify some items as sequential, and some as available to work on in parallel. But there is clearly something missing. You can start cooking the eggs before emptying the dishwasher, or buttering the toast. You have to empty the dishwasher before putting the cereal in the bowl, but you can put the cereal in the bowl before cooking the eggs. Would it not be clearer to represent the ordering of the tasks in the following manner?
It turns out that these more accurate dependency relationships are impossible to represent in a hierarchical manner. In actuality, many of our plans and todo lists actually have many-to-many dependencies, and we struggle with how to represent these in our various checklist apps. We accomplish this by compromising and making mental notes to ourselves, and we might not even be bothered by it except for once in a while. This mimics our tolerance of hierarchies in the physical world. Having learned to look past our frustration in the physical world, we look past it in the non-physical world as well, even though we don’t have to.
So even when we have the theoretical ability to use many-to-many to represent our thoughts, we do not, even though Hierarchies Are Overrated. Again, what is the conclusion we can draw here?
We’ve shown that we have the ability and theoretical opportunity to use Many To Many. We’ve shown that we often misunderstand it, and that we do not use it to the extent that we could. It appears that we simply have not learned to use it to its capabilities.
It is also clear we have become accustomed to tolerating a frustration against hierarchical models, even when we don’t have to. A solution is needed for this as well.
Finally, we can introduce our first value statement that will support many of our future conclusions. If something has utility, it should be utilized. This is at best a philosophical statement, but it is one we will adopt here, and it will reappear several times in the future. And so we reason: if we have not learned to use Many To Many to its capabilities, and if Many To Many should be utilized, and if we are accustomed to putting up with a problem that Many To Many can solve, then the proper conclusion is that Many To Many Needs Advocacy.
