Simondon, and Why Good Tools Converge
Technical objects become concrete when parts start serving several functions at once. The Guimbal turbine, and what the idea says about design tokens and variable fonts.
Date
Category
Writer
Put a generator inside the water pipe of a dam. Make it so small that it looks as though it must burn itself out. Then fill its casing with oil. The oil insulates the windings, carries heat away into the surrounding water, lubricates the bearings, and keeps the water out. Four jobs, one substance, and the machine only works because the river it draws power from is also the thing that carries its heat away.
That is the Guimbal turbine, and Gilbert Simondon uses it to make a point that is not about turbines. In his essay "Technical Mentality", translated by Arne De Boever for Parrhesia, he describes the arrangement exactly:
This disposition is made possible by putting the alternator in a casing filled with oil, which heightens the isolation and improves the thermal exchanges, all the while ensuring the lubrication of the different levels and preventing water from coming in: here, the multifunctional character of the oil of the casing is the very schema of concretization that makes the invention exist, as a regime of functioning.
"The multifunctional character of the oil" is the whole concept in five words. Simondon is not praising efficiency. He is describing a specific direction that technical objects move in as they mature, which he calls concretisation, and he thinks that direction is observable, law-like and mostly ignored by the people who write about technology.
The book, and its bibliographic mess
Du mode d'existence des objets techniques was published in 1958. It is in three parts: the genesis and evolution of technical objects, man and the technical object, and the essence of technicity. For roughly sixty years English readers worked from an unauthorised translation by Ninian Mellamphy, dated 1980, which is the text cited as "Simondon, 1980" in most of the older English scholarship and which I quote here because its pagination is the one that circulates.
The complete authorised English translation, by Cécile Malaspina and John Rogove, appeared in 2017. Here is a small wrinkle worth knowing if you are going to cite it: Simondon's own foundation lists it as published by Univocal Publishing on 10 April 2017, while booksellers list it as University of Minnesota Press, 18 April 2017, ISBN 9781517904876, 310 pages. Univocal was absorbed into Minnesota, which explains it, but I could not confirm the exact imprint history from a primary source, and the two dates coexist in catalogues.
A cassette recorder by Dieter Rams. Photograph by Jennifer Balaco, CC BY 2.0, via Wikimedia Commons.
Abstract and concrete
The distinction is the engine of the book and it is frequently reversed by people who assume "abstract" means simple and "concrete" means complicated. It is closer to the opposite.
An abstract technical object is one in which every part is a specialist. Each element is designed to do its own job as well as possible and to stay out of the way of the others. Simondon's example is the early internal combustion engine. As Vincent Bontems summarises it in Techné, "In the old engine, each element gets involved at a precise stage of the cycle, then it is supposed to remain still and not interfere with the other elements." The parts are conceptually clean, which is why Simondon calls the object abstract: it is assembled out of ideas, each idea kept separate. The cost is that it "needs to be constituted as a closed system in order to function", because any interaction between parts that was not designed in is a fault.
A concrete technical object is one in which parts have stopped being specialists. "It could be said that the modern engine is a concrete engine and that the old engine was abstract" (p. 19). The classic illustration is the cooling fin on an air-cooled cylinder. It starts as a heat-exchange device. Then, as Simondon puts it, "In recent engines, these gills have an added function of a mechanical kind, that of preventing the buckling of the cylinder-head under gaseous thrust" (p. 20). The fin is now simultaneously a radiator and a structural rib, and the object has become, in his word, bivalent: "the volumetric and mechanical unit has become co-extensive with the heat-dispersal unit because the structure of the whole is bivalent" (p. 20).
The general statement is that "in a technical object which has become concrete, a function can be fulfilled by a number of structures that are associated synergetically" (p. 30). Simon Mills, writing in the Fibreculture Journal, quotes the criterion in its tightest form: in a concrete object "no secondary effect either compromises the functioning of the whole or is omitted from that functioning". That is the test. Not that there are no side effects, but that no side effect is wasted and none is fought.
And the mechanism by which this happens is internal, not external: "The technical being evolves by convergence and by adaption to itself; it is unified from within according to a principle of internal resonance" (p. 19). Note the phrase "adaption to itself". The object is not converging on the market or on a user. It is converging on its own conditions of working.
Property | Abstract object | Concrete object |
|---|---|---|
Parts | One function each | Several functions each |
Side effects | Suppressed or tolerated | Recruited into the functioning |
Environment | Must be held constant | Participates in the functioning |
Additions | Solved by adding a part | Solved by redistributing functions |
Failure mode | Interference between parts | Whole ceases to be coherent |
The correction: concretisation is not styling, and not shrinking
The version of Simondon that circulates in design circles usually comes out as "things get more integrated over time", which is then used to justify whatever consolidation someone was already planning. Bontems states the exclusion directly: "Evolution of the external appearance of an object, uncorrelated with an internal reconfiguration, is not part of the concretization process."
That sentence eliminates most of what gets called convergence in product work. A redesign that unifies the surface while leaving the underlying parts exactly as separate as they were is not concretisation in Simondon's sense. Neither is packing more into less space. Concretisation is a change in the assignment of functions to structures. If you cannot name a part that now does two things it did not do before, nothing has concretised.
It also runs the other way. Simondon is not saying that integration is always progress or that the concrete object is better by every measure. He is saying it is a real direction, that technical lineages travel along it, and that "the evolution of a technical lineage leads to a totally unified technical individual". Whether you want a totally unified individual depends on what you are building.
The technical individual, and the associated milieu
Simondon works at three levels, and the middle one is the one people mean when they say "a machine". "The modalities of this genesis make it possible to grasp the three levels of the technical object and their temporal, non-dialectic coordination: the element, the individual, and the ensemble" (p. 15). An element is a part with a technicity of its own, a bearing, a valve. An individual is a functioning whole with its own environment. An ensemble is an arrangement of individuals, a workshop, a factory, a network.
What makes something an individual rather than an assembly is the associated milieu: the environment the object creates and then depends on. Mills glosses it as "the mediator of the relationship between manufactured technical elements and natural elements". In the Guimbal turbine the associated milieu is the oil and the river together, and it is created by the machine's own operation. Which is why Simondon says such objects cannot be arrived at by iteration. Mills quotes him: "Technical objects which in their liaison with the natural world put into play what is essentially a recurrent causality must be invented rather than developed in stages, because such objects are the cause of their own condition of functioning."
That is the least comfortable sentence in the book for anyone who believes in incrementalism. Some concretisations are not reachable by improvement. The turbine is absurd until the oil is there, and the oil only makes sense once the alternator is already small enough to be absurd. You have to make both moves at once or neither works.
Against treating machines as utility
The introduction is a polemic, and it is aimed at exactly the attitude that treats a machine as a means and nothing else. "Culture has become a system of defence designed to safeguard man from technics" (p. 11). The machine is then "a stranger to us; it is a stranger in which what is human is locked in, unrecognized, materialized and enslaved, but human nonetheless" (p. 11).
His alternative image is better than the argument around it: "Far from being the supervisor of a squad of slaves, man is the permanent organizer of a society of technical objects which need him as much as musicians in an orchestra need a conductor" (p. 13). The Simondon foundation states the claim flatly: "The opposition drawn between culture and technics, between man and machine, is false and has no foundation", and locates alienation not in machines but in "non-knowledge of its nature and its essence, by way of its absence from the world of significations". The publisher's summary of the 2017 translation puts the ontological demand plainly: "one must grant to the technical object the same ontological status as that of the aesthetic object or even a living being".
Practically, for anyone who builds things, this means judging a system by its internal coherence and not only by what it delivers. That is not an aesthetic preference. It is the claim that a system which is incoherent internally will keep producing problems that look like separate problems.
What concretisation says about design systems
Design systems are abstract technical objects almost by construction. They are built by listing functions and assigning a component to each. Every new requirement arrives as a request for another component, which is precisely Simondon's description of the abstract object: additions are solved by adding parts.
The Design Tokens Community Group's Format Module describes the state of play in one sentence: "While many tools now offer APIs to access design tokens or the ability to export design tokens as a file, these are all tool-specific. The burden is therefore on design system teams to create and maintain their own, bespoke 'glue' code or workflows." Glue code is the exact symptom Simondon predicts. When each part is a specialist, the connections between parts have to be written by hand, and the handwritten connections are where the system rots.
A token itself is a modest thing: "A (Design) Token is information associated with a human readable name, at minimum a name/value pair." What makes a token system concrete rather than abstract is whether one token does several jobs. A spacing value that also determines a line height, an optical size axis that also drives a tracking adjustment, a contrast threshold that also selects an icon weight. Those are single structures fulfilling multiple functions. A system where every property has its own independent token is clean, auditable and abstract in Simondon's precise sense, and it will grow without limit.
The best concretised object in current typographic practice is the variable font. Microsoft's OpenType specification describes it without philosophy: "OpenType Font Variations allow a font designer to incorporate multiple font faces within a font family into a single font resource", and variable fonts "provide great flexibility for content authors and designers while also allowing the font data to be represented in an efficient format". The mechanism was first introduced by Apple in TrueType GX. One set of outlines plus deltas replaces a folder of independent files, and the same delta data serves both storage and interpolation. Two functions, one structure. That is concretisation, and it is why variable fonts feel qualitatively different to use rather than merely smaller.
Where I would not push this
Simondon's technical objects are physical, and the reason their evolution has a direction is that matter constrains them. Heat has to go somewhere. A fin that is in the airflow is already in the airflow, so giving it a structural job costs nothing. Software has very few constraints of that kind. Two functions can share a structure in code without any physical reason to, which means convergence in software is a choice rather than a pressure, and choices can be made badly. A design token that does three jobs because three jobs happened to be nearby is not concretised, it is overloaded, and the difference is whether the functions belong to one regime of functioning or merely to one file.
I also want to be honest that I am reading an unauthorised 1980 translation alongside quotations from secondary literature, and that page references differ between editions. Mills cites the closed-system passage at page 14 where my copy shows it at page 19. Anyone building an argument on a particular sentence should check it against the 2017 Malaspina and Rogove text, which I have not done.
What survives all the caveats is the test, and it is unusually strict. Good tools converge not because convergence is elegant but because a part that serves several functions has fewer edges to go wrong at, and because a system whose side effects are put to work has stopped fighting itself. Everything else is a restyle.
Sources
Gilbert Simondon, On the Mode of Existence of Technical Objects, trans. Ninian Mellamphy, 1980 (original Du mode d'existence des objets techniques, 1958). Part I scan; quotations at pp. 11, 13, 15, 19, 20, 30. topologicalmedialab.net/xinwei/classes/readings/Simondon/OnTheModeOfExistenceTechnicalObjects/English/Part%201/SimondonGilbert.OnTheModeOfExistence.pdf
Gilbert Simondon, "Technical Mentality", trans. Arne De Boever, Parrhesia, pp. 17 to 25. Source of the Guimbal turbine passage at p. 19. parrhesiajournal.org/parrhesia07/parrhesia07_simondon2.pdf
Vincent Bontems, "Gilbert Simondon's Genetic 'Mecanology' and the understanding of laws of technical evolution", Techné: Research in Philosophy and Technology, volume 13, issue 1, Winter 2009, pp. 1 to 12. Source for the old engine's isolated elements (p. 3), the unified technical individual (p. 4), the cooling fins serving solidity (p. 5), and the exclusion of external restyling from concretisation (p. 6). scholar.lib.vt.edu/ejournals/SPT/v13n1/pdf/bontems.pdf
Simon Mills, "Concrete Software: Simondon's mechanology and the techno-social", Fibreculture Journal, issue 18, 2011, article FCJ-127. Source for the "no secondary effect" criterion, the closed-system formulation, the associated milieu as mediator, and the recurrent causality passage. fibreculturejournal.org/fcj-127-concrete-software-simondons-mechanology-and-the-techno-social/
Gilbert Simondon foundation, "On the Mode of Existence of Technical Objects", catalogue entry. Source for the three-part structure, the 2017 Univocal translation by Cécile Malaspina and John Rogove dated 10 April 2017, and the quotations on culture as a defence system and on alienation as non-knowledge. gilbert.simondon.fr/content/mode-existence-technical-objects
MIT Press Bookstore listing, On the Mode of Existence of Technical Objects, University of Minnesota Press, 18 April 2017, ISBN 9781517904876, 310 pages. Source for the alternative imprint and date, and for the "same ontological status as that of the aesthetic object or even a living being" description. mitpressbookstore.mit.edu/book/9781517904876
Design Tokens Community Group, Design Tokens Format Module, draft community group report. Source for the definition of a design token and the statement about tool-specific exports and bespoke glue code. designtokens.org/tr/drafts/format/
Microsoft, "OpenType Font Variations Overview", OpenType specification 1.9.1. Source for the single-font-resource description, the efficiency claim, and the origin of variation mechanisms in Apple's TrueType GX. learn.microsoft.com/en-us/typography/opentype/spec/otvaroverview
Related reading
Latest Articles.
© Moc Mallen Studio
Thoughts, ideas, and perspectives on design, simplicity, and creative process.
.jpg){kind=link}