What is quality in software?
In a 7.24-minute long spoken word stream, and in a post on her blog, Jessica Kerr attempts to explain why this question is so hard to answer. But Kerr also hints on one secret for quality software.
If you would summarize Kerrs view, she says, in my interpretation, that no representational system we humans can conjure, for fixating the complexity of a system, fully does so; thus, rather than attempting to make use of some wet blueprint, attempting to explain every aspect of the system — the modernist architect in a nutshell — it’s better to acknowledge our limits and frailty as humans, and put our energies into lesser tasks, small units we know how to and so by reducing uncertainty and making us somewhat less ignorant.
Quality, your nature is a secret.
Still, being aware of one’s partial ignorance, is better than the false pretense that the system is fully comprehensible.
How does Kerr propose we relate to quality in software?
Firstly, what should we think about this thing we call a complex system? I think there are striking similarities between Kerrs view and Herbert A. Simon’s view in Architecture of Complexity (1961).1 ‘Roughly, by a complex system I mean one made up of a large number of parts that interact in a nonsimple way. In such systems, the whole is more than the sum of the parts, not in an ultimate, metaphysical sense, but in the important pragmatic sense that, given the properties of the parts and the laws of their interaction, it is not a trivial matter to infer the properties of the whole. In the face of complexity, an in-principle reductionist may be at the same time a pragmatic holistic.’
For instance, the main merit of TDD, unit-tests, microservices and functional programming in this larger, more philosophical outlook is according to Kerr, as I understand her, that they are containers of complexity.
If the thing named complexity is of a size, we can reduce this size by splitting the thing into lesser parts, parts we can treat as units in isolation, and so by doing so having one worry less.
Kerr seemingly advocates microservices with Unix-like arguments. So also by emphasizing the merits of functional programming whose small composable units, are easier to validate than the schemes of large-scale logic. However, what’s most interesting is Kerr’s critique of what could be called technoscientific abstractions.
When doing science we sometimes get so entangled with purity, that we forget that while some aspect of reality may be captured with a perfect abstraction, we understand very little of reality and least of all our selves. The layers of irrationality residing in us cannot be shaken off, and in the end, it is we who use scientific or engineering abstractions to close in on reality.
A complex system, in this view, is always surrounded by secrets — aspects that can’t be fully understood. However, this does is a factual, note an ontological, statement; Kerr does not say that, in theory, a complex system could not by understood. She merely concludes that it highly unlikely we would uncover all layers, all veils, every aspect of a complex system, especially not it’s an “open system”, impregnated by the emotions and thought of humans, both with regard to the developers and the users.
Mind that she does not criticize the technoscientific ideas in themselves; too me it seems, she only criticizes the mental models that arise from them when we use such abstraction in isolation, apart from the living document that is a system, and those who use it.
If a complex system rather would be understood as a node than a thing, how should we represent this?
No science of today has a good enough grasp of the complexity of human existence, society, and our world. And if this is true, why not represent the dialectics between parts with literary techniques? It’s at least a possible explanation of why Kerr chooses to present her view in a spoken word-version. This sounds like something that would fail, something which would only end up with cliches. But she doesn’t. I highly recommend the spoken word-version as Kerr masterfully makes use of tonality, gesture, and mime to communicate her message on quality in software.
Kerr calls the form ‘spoken word’, but I’d rather speak of this as a one-person drama, performing a Socratic dialogue.
In the dialogues of Socrates, written by his disciple Plato, Socrates/Platon externalize different standpoints in personas, and explain why a set of arguments are misleading, contradictory, and false by asking questions and using logic. Sometimes Plato lets his master propose an alternative view of an aspect of reality. But some dialogues may also end with a sort of enlightened uncertainty. And this is what Kerr aims for in my interpretation.
What you meet are personifications of powerful Engineering perspectives, and questions from a more… Human perspective — the user perspective, but also the perspective of the flesh and blood developers.
For each abstraction, and for each interaction with the human side of the product and product development, the Web thickens, or like overlapping threads producing a fine canvas.
Whatever technology we choose, Kerr seems to claim to we should not forget that the users and producers are entangled in the product. Something that may, or may not, have consequences related to our design choices regarding technology.