There is a famous saying by cyberneticist Stafford Beer that “the purpose of a system is what it does,” also known as POSIWID. In the following, I will argue that with software systems, their purpose is what you can do with them. I’m refraining from coining an acronym for that.
Recently I have described two of my own ideas for software systems,[1] both of which distinguish themselves by having ultra-small and very, very general base models. One system features Items, which can be related to other Items, and that’s it. The other has Identities, Relations, and Personas. I settled on these categories based on the insight that knowledge is difficult to put “into boxes” and that such categorisation is best delegated to actual humans—who do that all the time. That each user can “express” their own model this way, however, is as much a feature as others might see it as a bug; having no standardised categories limits comparability—naturally.
To understand the history of ideas, when looking at a particular school of thought or thinker, it is often a good starting point to ask what they reacted against—what flaws in the existing ways of thinking did they seek to remedy? A bit of that was going on with my choice of those abovementioned data models as well. It happened like this.
Back in the day we were working on an archaeological field recording system, which was a product of academia. A core member of our team pushed hard for our data model to be of highest generality, which I pushed back against. My take was influenced by having at the time discovered the English-speaking literature on software engineering, which for its pragmaticity appeared a very attractive antidote to the sometimes overly dry academic research environment. (Amongst the things I read were for example Domain-Driven Design by Eric Evans and Applying UML and Patterns by Craig Larman, and for all sorts of reasons I was very much in love with the idea of “modelling the world”).
My main argument for having our model not fully general was the rather simple observation that when something is general, the system can only treat it in a general way. Neither can it limit what you can do with that general object (compared to all other objects), nor can it let you do anything special with it (again, compared to the other objects). We eventually ended up modelling very few categories, amongst them Feature, Find, Trench and Place. A Trench, for example—in the real world the area of excavation, where real people worked digging up real “stuff”—could thus get its own “tab” in the application, something we wouldn’t want to offer for, say, a Coin.
In the end, we drew the line at probably the right boundary. We could hardcode some behaviour into our application, while leaving a lot of room for the users to customise.
You have to know that the problem with all modelling in the humanities is that rarely two people, but never two groups of people agree on a model—on what things exist and how they hang together. And this showed here, since the system was conceptualised from the get-go as distributed and customisable; which is to say teams of archaeologists take the system to their excavations and enter their findings in a structure which matches their very own ideas—influenced by the project leads’ views on things and the research question to be answered.
Back to my own systems which I mentioned above. To go for full generality was my reaction against my own former intuition—to see what happens; sometimes breaking one’s own resistance in this way can be a great learning experience. Being able to—in full acuity—perceive modelling options to come in the form of a spectrum from full generality to full specificity was my reward.
Here is a summary of my understanding.
Visicalc [commons]
Two types of systems which offer a high degree of generality are databases and spreadsheets. In databases, arbitrary things with arbitrary relations can be modelled. Mind you, this is how it looks from the perspective of the application developer. The job of the application developer is to actually use this general model to implement a concrete model, the domain model, on top of it. With spreadsheets, the user starts with a matrix of cells, arranged in rows and columns. The meaning of every cell, row and column is undetermined, until the person sitting in front of the computer concretises it—for example by adding headings. Again, a concrete model is expressed in terms of a more general model.
What is going on here is that users limit their own options in order to achieve specific goals. A naked spreadsheet or database says nothing. Expressivity comes from differentiation. A system can only work with differences. When a system offers a model which distinguishes two types of entities, EntityType-A from EntityType-B, somewhere within that system a corresponding “if” branch can work with that difference and present entities of those types in different manners, or allow for different interactions.
The more general the model the system offers, the more open it is for the user to “bring their own model,” which puts the responsibility to react to the model on the user. For example, in spreadsheets this means that users enter formulas, to enact behaviour according to what certain cells “mean.” In another system, one might be able to assign colours to entities of different types, etc.
But high degrees of generality come at a cost. One has to configure everything. Accordingly, we experienced a sort of “configuration hell” in our archaeological system. Maintaining such basically “unstructured” data, especially across projects, proved a formidable challenge.
A part of the price to pay for generality consists in the fact that comparability is severely limited. This is why all software aimed at end-users is specific, and built with an explicit domain model. The domain model is abstracted from the real world in a collaboration between software developers and domain experts. There is an understanding that the system is in a sense a representation of the real world domain, which I happen to think—is wrong. What “is” the case in a given domain—this is the correct way to see it in my opinion—is translated into what can be done inside the system.
All (interactive) software exists to allow users to achieve goals. The interesting thing here is that quite often the mental models of users diverge from the “domain model” which has been gathered and distilled by the software creators. Often this leads to frustration on the side of the creators, who may perceive users using the system in unintended ways as ‘abusing’ it. Sometimes, in all fairness, it is conceded that users merely circumvent existing limitations of the system creatively with “workarounds.”
The problem is—as I never get tired of pointing out—that no two models of two people or groups of people are the same. Furthermore, models are not stable across time. Concretely, in a software company the model is constantly in flux to a certain degree: new requirements get implemented, and the different people working on the system are not one hundred percent aligned in their own models and understanding of the system, traces of which leave imprints in the code. Next, the model is often not fully consciously designed and chosen, and alignment is often not updated and enforced.
My upshot from all of this is that whatever the intended purpose of a system is, in the end only what the user can do with it matters.[2] Any system allows certain things, and limits options in certain other ways. Whatever the purported domain model of a system is, users have their own minds and will use the system in whichever ways they see fit to achieve their own goals.
Mind you, that does precisely not mean that software creators can just offload the burden of modelling onto their users. I remember having seen a demo by Steve Jobs from the heyday of database systems à la Access. In contrast to spreadsheets, this never really took off.
So, finding the right cutoff point—finding the right balance—between what is modelled and what is unmodelled, and making this a deliberate choice, may possibly be one of those underexplored and underutilised design options which can make a huge difference in the success of a piece of software, which is what I hope to have demonstrated with this article.
Footnotes
Personalist and Rhizome.
In other contexts this is referred to as “affordances.” That which an artefact allows one to do with it.