Notes on the process of writing software.
How do we make the world better through the code we write?
Dora metrics as heuristics of a living system - we can explain why these metrics are useful to indicate such a system, and maybe derive some more metrics
Software is a socio-technical system that can be said to be alive - both in the sense that it is dynamic but also in the sense that it’s topology creates a structure that is able to create affect on its composite agents - both human and computer. Rather than a binary, this system can inhabit a range of liveliness from human-like-alive to completely dead, and different aspects and moments within the system can exhibit different qualities. Ultimately, software is like a pre-literate epic poem, collaboratively created and embodies over time and structured in a way as to survive its multiple authorship and maintain and strengthen its affect.
Phenomenology and poetics are therefor just as important useful in the development of these systems as mathematics. We must engage in what Nim Daghlian terms “conceptual labor” as well as perform what Keller Easterling calls “Medium Design” in order to push the boundaries past implementing off the shelf solutions and delivering known-quantity information commodities for known-quantity sums of money. This is hard and time consuming, which translate pretty clearly into “expensive”.
The question than becomes; How do we write software that has a relatively high value (monetary output) compared to the cost of its creation?
What does it mean for software “to be valuable”?
- Embodyment of moral positions
- Creates an arbitrage gradient which collects money.
Creating a human layer of interaction with an inhuman layer of math. The human-ness of this layer is directly related to the arbitrage-gradient it creates. See the time honored silicon value template of creating usable interfaces to AWS services as products.
Connections between geometric structure and topological structure.
agency and ownership over the whole of a system.
A user interface is defined in terms of what it prevents a person from doing; what barriers does it put in place, what outcomes does it wish to prevent? In a possibillity space where any input can be accepted, what needs to be cut away?
“value engineering” as an approach; given this amount of money, what can be done? Opposite to the other way; this needs to be done, how much money will it take?
Fixed-price, variable-scope projects are sensitive to the wholeness of the problem space, which naturally concerns money.
Money in a project can be spent or invested. Money invested is expected to produce a return – in software terms the money gained by a running system is greater than the money spent writing and maintaining it. On the other hand, money spent has no expectation of a return; the money is being used to purchase an outcome which is valued on its own, independantly of financial benefit.
Metrical and analytic decision making through data analysis alone is not enough to make good work. Instead, they are merely tools used to see and understand the wholeness of the system, and to understand if changes made to the system are enhancing the wholeness. Human feeling is the key driver, and data analysis can be used to persuade for or undermine an agenda based on feeling. And that’s not even getting into the use (or lack thereof) of approraite analysis tools to ensure confidence and appropriateness of waht’s being measured.
Derek K Jones writes that almost none of the contemporary industry standards in software engineering have any basis in evidence that they work in any meaningful way.
Musks takeover of Twitter further underscore this point, as what he is doing to an engineering project “should” kill it. But as Majors notes, something like Twitter is very hard to kill.
Having a clear language and shared understanding around the structure of data and relationships of that data allows applications that interface with that data develop simply and easily. The process ceases to be “what data structures do we need to enable this process” and becomes “what processes arise from this data structure”.
Software is not defined by what it allows a user to do, but what it prevents a user from doing, and differentiating the remaining options from each other.
The slow work of getting it right.
Software is neat because a sufficiently detailed model of the system is the actual system
Software is hard because the information environment that makes up the wholeness is very difficult to perceive. Architects have it easy, they go to a place and have immediate access to a wealth of information. Software on the other hand, can neither confirm nor deny anything. Understanding the wholeness that stretches out beyond our project - even understanding the wholeness of our small project itself! - is a very difficult thing to do and almost impossible to know if we have all the relevant information we can have.
The tools we use define the outcome of the work - a human face can’t be drawn with a t-square and a ruler, to paraphrase Christopher Alexander. Many of our tools in a software system are built from the needs and perspectives of computer science and not the perspective of human systems. These two approaches are fundamentally at odds with each other, and in any software project one must be sublimated in the service of the other. It’s an ethical position to state that the computer must be sublimated to the human.
The Process of Writing Software
- Understand how much attention the team writing this software has.
- Understand how much money your teams attention costs.
- Understand the benefit of writing this software in relation to the cost of your teams attention.
- Determine how much attention is worth spending on the project at this point.
- Work with the entire team, and ideally all the people affected by the software, to develop a language around what you are trying to do.