Somewhat related to LimitsOfHierarchies
, but not the quite the same, lists of mutually-exclusive (M.E.) categories or types are often a big source of scalability problems I have observed after working and contracting in a dozen+ companies of all sizes. The simplest example is a M.E. category system used to describe products, actions, stages, etc. When the system starts out small and simple, such may be satisfactory. However, as it grows in size or complexity, mutually-exclusive categories or sub-types start to fall apart. Often things fall into more than one category, for example, and to keep a system designed for M.E. you have to create a kind of CartesianJoin
of factors for new codes if you want to capture multiple classification slots.
As you might expect, I am going to say some kind of system generally based on or influenced by SetTheory
will scale better. However, it seems many existing tools are not really well-tuned to deal with sets. Set handling in tools is kind of an after-thought in many cases such that the work to prepare for them may be PrematureAbstraction
especially when FutureDiscounting
is used. But if you are preparing up-front for expected uncertainty and change, then the bit of extra effort up front may well be worth it.
Any list beyond about 15 will usually start showing signs of trouble. I challenge anybody to provide a list of M.E. classifications from the real world beyond 20 that are free of problems or partial duplication.
atoms -> elements
molecules -> chemicals
There are hundreds of mutually exclusive (M.E.) classifications for elements: for example, there is one mutually exclusive category per element, based on the number of protons in the nucleus. There are also mutually exclusive categories based on the number of valence electrons for each atom in rest-state, and a mutually exclusive category for the noble gasses, and so on. Similarly, there are millions of organic and inorganic chemical compounds classified exclusively in terms of both their atomic structure and the physical bonds between them - millions of mutually exclusive distinctions. These two examples are, to a lucid and rational reader, very damning to your above assertion that MutuallyExclusiveCategoriesDontScale, and are certainly higher on the EvidenceTotemPole than your ArgumentFromAuthority ("I observed it in a dozen+ companies; the categories or sub-types start to fall apart; believe me!")
Plus, it's hard to test scaling unless God gets bored with the existing set.
How about a real example of your experiences, where things worked before and didn't when the list grows to about 15?
The list of "action codes" started out something like this:
IA - install product A
UA - upgrade product A
TA - test product A
RA - remove product A
IB - install product B
UB - upgrade product B
TB - test product B
RB - remove product B
Then when more bundled deals appeared, one could often do the same thing to both product lines. Thus, a new set of codes was introduced:
I2 - install product A and B
R2 - remove product A and B
Upgrading and testing at the same time were relatively rare, so they were generally not tracked as being "both". However, third and fourth product lines appeared and the list indeed grew a CartesianJoin
feel to it. Now the codes are almost useless and are being supplanted with a more set-oriented architecture (independent of my involvement), but they still try to use the old codes because everybody has grown used to them.
It is now clear that the most normalized approach is to not hard-wire the action to the product kind, and that there may be multiple actions per customer visit. However, I agree that doing this early on when there were fewer and simpler products may have been PrematureAbstraction
Another example is Email folders. Sometimes I want to search by sender, sometimes by project name, sometimes by project category(s), sometimes by project requester, sometimes by sent-date, sometimes by attachment type, etc. No single list of folders is sufficient to do this, and even with search options one has to select a particular folder to use the search options with our lame email software.
See also: LimitsOfHierarchies