Differentiae – where is the difference
In an article from August 2019 my friend Damian Synadinos taught me about the concept of “differentia”. The distinguishing characteristics of a thing that makes it possible to differentiate it from another thing.
In the DSRP-method for systems thinking, D stands for Distinction. It’s all about what a node of the system is and what it is not. Sometimes that’s as easy as, this tree is this tree and not all the other trees around it. Sounds stupid, but can be that simple. Not always it’s that simple. Where do you draw the border between a thing and not-a-thing. And is the border part of the thing or not?
The distinctive element of a node in the system can be very helpful. Let’s go back into the world of IT and look at a service that handles log-ins. This service is responsible for authenticating users. In one case it is not responsible for storing the user’s real name. In another case it is. So it can be helpful in the description of a service what its responsibilities are. It can also be helpful to distinguish what the service is not responsible for. This creates a clearer expectation towards the service. It handles the login, but not the storage of further user data. This defines the borders of the element better.
Maybe you have to dissect the node into smaller parts to find the differentia. Take two types of trees for example. On first sight they might be similar. But then you look at the parts, like the bark, or the leaves, or the fruits. Maybe the bark looks the same, maybe the fruits look the same. But the leaves have distinguishable elements. That might not help in winter, when the tree lost all its leaves. Then you need to keep searching for further distinguishable elements.
The differentia can also help to describe your job. The job description can be a list of tasks that your role has to do. Are there tasks your role will not do? Are there tasks your role could do but doesn’t have to? Where does your role start and end? That a tester is not responsible for finance and controlling might be obvious. But actually, I had that task as a tester once. For a while I was taking care of my team’s controlling. Was that in my job description? Probably not. But was it excluded in my job description? No. Would it make sense to create a job description with that amount of information what your job is not? Not at all. But there might be important details that should be listed, that you don’t have to do. One of the most important elements of the job description for me was: “Don’t need to travel, if you don’t want to.”
When a small child sees a cat, it knows it’s a cat. Cats all look roughly similar. The differentiae are not that huge. Though the same happens for dogs. A small child knows that it is a dog, no matter if it’s a Chihuahua or a German Shepard. The differentiae are quite enormous. But the dog typical elements seem to be clear as well. So there is something about dogs that makes it clear that it is a dog and not something else.
So, it is important to describe what it is, but also to a useful degree what it is not. Next time you describe an element of a system. Think about what it is not. And it will become much clearer what it actually is.
