Gilbert Simondon

There Are No Good Philosophers of Software

/ Adam / 3 Comments

There are no good philosophers of software.

There is some good philosophy inspired by software, or on the society created by software, or on how software changes the way we think.

There is no good philosopher of software construction.

That is the provocation I threw out on Twitter in response to Hillel Wayne‘s excellent prompt, two and a bit months ago.

The provocation got some attention, and what I was hoping for even more, some excellent responses, and suggestions for new things to read. It definitely highlighted some gaps on my side. But I honestly do feel there is a hole where the philosophy of software construction should be, and that the world feels this lack keenly, especially when we consider how ubiquitous software is in sensing, controlling, and mediating that world. So I’ve recapped the original thread below, as well as some good responses to the original prompt, especially ones that point in interesting new directions.

Deleuze and Guattari describe philosophy, as distinct from art and science, as the creation of concepts.

Cover of Wimsatt - Reengineering Philosophy for Limited Beings

Hillel (the OP) thinks deeply and reads broadly on software construction. I would argue that there is no writer creating deep concepts for software construction as part of a larger project.

This isn’t really an anomaly. It’s because there is very little philosophy of engineering.

The two really compelling books I would put in that category are Simondon’s On the Mode of Existence of Technical Objects and Wimsatt’s Re-Engineering Philosophy For Limited Beings. Simondon only had readily available English translations relatively recently, and should be read more. This book analyses how machines improve through being recomposed in their broader context (milieu). A key concept is concretisation: replacing theory with realized parts. Wimsatt is great and you don’t have the translation excuse. He also touches on software and programming, but is not really a philosopher of software. A key concept is “ontological slime”, spaces of symbolic irregularity which have no simple organizing theory.

Otherwise, there is philosophy which theorises software and uses its concepts to describe the world – such as Sadie Plant’s Zeroes and Ones, or Benjamin Bratton’s The Stack.

There is writing which gives a sense of what computation is – such as Hofstader’s Gödel, Escher, Bach. “Strange loop” counts as the creation of a concept, so it is philosophy, or maybe theory-fiction. Laurel’s Computers as Theatre also fits here.

Cover of Simondon - On The Mode of Existence of Technical Objects, Mellamphy trans.

There is philosophy on the ethics of software, which is mainly about telling programmers what to do. This is fine so far as it goes, but not really a philosophy of software, and often not very software-specific.

There is philosophy written by mathematicians and computer scientists on the impact of computing: Turing’s paper Computing Machinery and Intelligence, and many such contributions since.

There is philosophy which sees computation as fundamental to the universe and intelligence, like Reza Negarestani’s Intelligence and Spirit.

There is philosophy which uses computation, like the analytical philosophers who write Haskell and develop theory provers like Coq, or Peli Grietzer’s Theory of Vibe.

There are software design guides which attempt to go up a level of abstraction, like Ousterhout’s A Philosophy of Software Design.

Then there are drive bys and fragments. Yuk Hui’s On The Existence of Digital Objects builds on Simondon and is probably in the neighbourhood.

James Noble’s classic talk on Post-Postmodern Programming:

Some work on computational materials by Paul Dourish, like The Stuff of Bits, and blog posts on the topic by Harrison Ainsworth and Carlo Pescio.

Abramsky’s paper Two Questions on Computation. Some essays in the Matthew Fuller edited Software Studies: A Lexicon. Other uncollected ramblings on blogs and Twitter.

But there is no coherent project created by a philosopher of software, such that I could point to a book, or ongoing intellectual project, and say “start there, and see your everyday world of software construction differently”.

The Project

A number of people pointed out that this long list of negations didn’t include any positive statement of what I was looking for. Let me fix that. A good philosopher of software would have:

  1. A coherent project
  2. That is insightful on the machinic internals of software
  3. In communication with philosophy, and
  4. That recognises software design as a social and cognitive act.

Hopefully that explains why I left your favourite thinker out. At least for some of you.

Misses

There are a couple of big misses I made in this informal survey of software-adjacent philosophy. There are some other things I deliberately excluded. And there were things I never heard of, and am now keen to read.

I got mostly software people in my replies, and a number of them brought up William Kent’s Data and Reality. I have read it, I think after Hillel’s enthusiastic advocacy for it in his newsletter. ((Personally I thought it was ok but not mindblowing. However, I listened to it on audiobook, which is definitely the wrong format for it, and in one of the late, mutilated editions.)) I would place it as a book in the Philosophy of Information, albeit one not really in communication with philosophy more broadly. The Philosophy of Information is definitely a thing in philosophy more broadly, one most associated with the contemporary Oxford philosopher Luciano Floridi. You can get an overview from his paper What Is The Philosophy of Information? Floridi has written a textbook on the topic, and there’s also a free textbook by Allo et al, which is especially great if you’re poor or dabbling.

I think there’s a lot that software people can learn from pretty much anything in my list, and the Philosophy of Information does shed light on software, but it only rarely addresses point (2) in my criteria: it does not give insights into the machine internals of software. Some of it is tantalizingly close, though, like Andrew Iliadis’ paper on Informational Ontology: The Meaning of Gilbert Simondon’s Concept of Individuation.

I also should have mentioned the Commission on the History and Philosophy of Computing. Though it isn’t really a single coherent intellectual project in the sense I mean above, it is an excellent organisation, and the thinking that comes out of this stream is most reliably both in communication with philosophy and insightful about the machine internals of software. This paper by Petrovic and Jakubovic, on using Commodore64 BASIC as a source of alternative computing paradigms, gives a flavour of it.

It wasn’t mentioned in the thread or the responses, but I’ve recently been enjoying Brian Marick’s Oddly Influenced podcast, which takes a critical and constructive look at ideas from the philosophy of science, and how they can be related to software. Often, given his history (he is that Brian Marick), he’s reflecting on things like why Test Driven Development “failed” (as in, didn’t take over the world in its radical form), or how the meaning of Agile has morphed into a loose synonym of “software project management”. That makes it sound like just a vehicle for airing old grievances: it’s very far from that, and always constructive, thoughtful, and ranges across many interesting philosophical ideas.

I mentioned Media Theory thinkers via Software Studies (which even includes Kittler), but it’s worth noting that media theorists have been thinking about software quite seriously, and there is some useful dialogue between software construction and design theory, usually restricted to the context of user interfaces. Wendy Chun’s Programmed Visions and Lev Manovich’s Software Takes Command are good examples. I first read Simondon because Manovich recommended it in an interview I no longer have to hand. And other people gave Kittler’s There Is No Software paper the name check it deserves.

Others pointed out that the Stanford Encyclopedia of Philosophy is rigorous, free, and has an article on the Philosophy of Computer Science.

Glorious Discoveries

The discussion unearthed some books and papers that look pretty great, but I hadn’t even heard of, let alone read.

  • Kumiko Tanaka-Ishii – Semantics of Programming
  • Federica Frabetti – Software Theory: A Cultural and Philosophical Study
  • M. Beatrice Fazi – Contingent Computation: Abstraction, Experience, and Indeterminacy in Computational Aesthetics
  • Reilly – The Philosophy of Residuality Theory

And a suggested side-quest from philosophy of engineering

  • Walter G. Vincenti – What Engineers Know and How They Know It: Analytical Studies from Aeronautical History

A Conciliatory Postscript

We can imagine both a broad and a narrow definition of the Philosophy of Software. In the broad definition, most things in this post would be included. And yes, academics, if there were a hypothetical undergraduate subject on the philosophy of software, it would probably be best to use the broad definition, and expose young developers to a broad collection of ideas about the way software works in the world. So I am not completely sincere in my provocation, but I’m not utterly insincere either.

There are delicate and intimate connections between software construction and philosophy. Consider the tortured, necessary relationship that both philosophers and programmers have with names, with intuition, or with causality. The possibility of exploring these connections, and inventing new concepts, gets swamped. It gets swamped by illiteracy and thinkpiecery on the software side, and by mechanical ignorance on the philosophy side. The narrow definition of the philosophy of software, and the recognition that there is no coherent philosophy of software construction, brings it back into view.

Metis and General Intellect

/ Adam / 1 Comment

“The general intellect” can be interpreted as tacit craft knowledge embedded in individual cunning and social relations. This definition sets general intellect in contrast and opposition to formal information systems. Framing it this way may not be completely true to historic usage, but has some revealing consequences. It applies to either abstract information machines like traditional bureaucracies, or concretized ones, like specific computer programs. Craft and process arguments in software development are also a lens on this transformation of skills in cognitive capitalism, information valorization and their relationship with bureaucracy and flows of stupidity. To expand the general intellect is to accelerate.

The term the general intellect (sometimes general social knowledge) originates from Marx and was used by operaismo thinkers to grapple with the emergence of cognitive capitalism. Virno states:

Whereas money, the “universal equivalent” itself, incarnates in its independent existence the commensurability of products, jobs, and subjects, the general intellect instead stabilizes the analytic premises of every type of practice. Models of social knowledge do not equate the various activities of labor, but rather present themselves as the “immediate forces of production.”

They are not units of measure, but they constitute the immeasurability presupposed by heterogeneous operative possibilities.

They are not “species” existing outside of the “individuals” who belong to them, but axiomatic rules whose validity does not depend on what they represent. Measuring and representing nothing, these technico-scientific codes and paradigms manifest themselves as constructive principles.

From here I suggest general intellect as a form of tacit and social knowledge, of metis, defined in contrast to formal knowledge, numeric or systematic knowledge. The general intellect is cognition but it is not data. It is highly contextualized, by experience, locality and specific social relations. James C. Scott offers the knowledge embodied by a soccer team or a ship’s pilot as good examples of metis. He also uses it in contrast to systematic forms of knowledge used in high modernist, often Fordist projects of top-down political control, state or corporate.

At the economy scale, the general intellect also seems to have an intersection with the idea of “institutions” in economic development. Institutions established ongoing government policies but also more abstract things like property rights and the rule of law; they are not primarily buildings, but persistent social relations, not commoditized or readily transferable between nations. Acemoglu and colleagues found significant correlation between historic settler mortality and modern economic success, putting forward the type of colonial institutions as the causative link.

Though this is oppositional with computation as a form of knowledge, the two are complementary in production. Operators draw on the general intellect to make machines work and produce things. This is true of concrete machines, like a coffee maker, or abstract machines in the Simondon / Deleuze / Guattari sense. And machines, especially large abstract machines, make use of operator black boxes to be effective. Traditional bureaucracy before the advent of modern computers and networks is an example of an abstract information machine which uses human operators as black box components – for instance to persist information to longer term storage, by writing on paper.

If we look at the skilled cognition involved in designing complex machinery, such as computer programming, we find the general intellect in the sense of individual and organizational craft knowledge. The rise of agile software development techniques, emphasising teamwork and craft skills over Fordist or high modernist planning, is one example of this over the last fifteen years. Yet the act of programming depends very much on an individual mental model, as pointed out by Naur. Programming is not typing; the main productive activity in programming is building a coherent mental model, the actual executable code produced is a side-effect. “Programming in this sense must be the programmers’ building up knowledge of a certain kind, knowledge taken to be basically the programmers’ immediate possession” (Naur). The spread of algorithms and software throughout society would then suggest a shattering of the general intellect into millions of shards of specific intellects. The general intellect – the entirety of system relations – could decay even as systemic shards expand in sophistication.

None of this is deny a certain translatability from metis to formalized knowledge. It can all be boiled down to bits in the end. Translation for functional use is costly and lossy, though. The mechanics of deep learning parallel this metic transformation from formal data structures into occluded knowledge. To understand how a deep learning system internally navigates a problem space requires a separate systematic analysis alien to the learning mechanism of the algorithm. Deep learning is a localized preview of machinic metis.

A countertrend to the fragmentation of general intellect might be the success of open source, but the point of open source is precisely to make the executable details of machines more readily available through social processes. It is a common platform rather than a general intellect, where evolution of the platform happens through patches (explicit formal communication) rather than primarily through evolved social understanding, though those dynamics still exist. It is striking that open source communities are organized primarily around a specific machine or platform rather than user products. This is true from the GNU C compiler through to the Apache web server and git source control. They echo Simondon’s critique of objects made in capitalism not evolving but merely accumulating features. Simondon’s comments on technical culture also parallel general social knowledge:

Now that he is a technical being no longer, man is forced to find for himself a position in the technical ensemble that is something other than the position of individual.

The trend for computer programming to promote skilling up for designers but sometimes exporting deskilling elsewhere was noted by Mackenzie in 1984; it’s because capitalism is a valorizing process rather than a deskilling process per se. Likewise there are deskilling trends in the software industry around outsourcing highly specific work to remote or offshore teams, so long as it promotes valorization (increases shareholder value).

The frustrations of working in or with a bureaucracy are often those of being a black box cog in a larger abstract machine, either through alienation from the meaning of the work, or because the work actually causes an undesirable effect which conflicts with personal goals, or even the stated goal of the organization itself. That is a form of stupidity but relates to all bureaucracy. Deleuze and Guattari say in capitalism:

The apparatus of antiproduction is no longer a transcendent instance that opposes production, limits it, or checks it; on the contrary, it insinuates itself everywhere in the productive machine and becomes firmly wedded to it in order to regulate its productivity and realize surplus value which explains, for example, the difference between the despotic bureaucracy and the capitalist bureaucracy.

eg in a despotic state the army may come and confiscate food and labour from a subsistence farmer when fighting a war, but in capitalism this military anti-production is in the form of a military-industrial complex, production interleaved with anti-production. Yet those critiques could apply to Soviet socialism too; only capitalism manages to create demand and ensure lack in the midst of overabundance.

Deleuze takes stupidity as an inability to dissociate from presuppositions, sense rather than common sense. Contemplating flows of stupidity, I am reminded of the slogan of engineer Jesse Robbins for making useful things in corporate bureaucracies: “Don’t fight stupid, make more awesome”. This could also serve as an accelerationist slogan, and can be critiqued the same way. Are you pushing forward as an elite ignoring politically hard problems, or are you building a concrete alternative solution that will attract change? Are you wasting time trying to change a system accelerated beyond human comprehension, or are you using accelerated human components to build a new system?

References

Acemoglu et al – The Colonial Origins of Comparative Development
Beck et al – Agile Software Development Manifesto
Deleuze and Guattari – The Anti-Oedipus
Garton – Excavating the Origins of Accelerationism
Land – A Quick and Dirty Introduction to Accelerationism
Mackenzie – Marx and the Machine
Naur – Programming As Theory Building
Scott – Seeing Like A State
Simondon – On The Mode of Existence of Technical Objects
Virno – Virtuosity and Revolution: The Political Theory of Exodus, in Radical Thought In Italy
Williams / Srnicek – #accelerate Manifesto for an Accelerationist Politics

Reducing Abstraction in Code

/ Adam / Leave a comment

Abstraction is something we are taught to value as programmers, and the process of finding common patterns across parts of a system is one programmers are usually good at. There is another equally important process of improving systems by collapsing redundancy and abstraction. Gilbert Simondon names this “concretization”.

Primitives

Concretization removes parts and makes machines more specific. A simple example is the abbreviation of clutter by replacing with clearer syntax. Say in Python

if available == True:
   reserve()

to

if available:
   reserve()

Or in JUnit:

assertTrue(false);

to

fail();

These are behaviour-preserving design improvements, or in other words, refactorings. They often turn up in novice programmer code or code written by people new to a language or toolset. Other primitive concretizing refactorings might be dead code removals, such as Remove Unused Parameter.

Another primitive concretization step is recognizing that a variable with a highly general type can be typed more precisely. A String, byte[] or a void* are highly general types, in that they can hold pretty much anything. Replacing with a more specific type usually relies on a precondition, either implicitly or explicitly.

int age = Integer.parseInt(ageStr);

In this case the potential throwing of NumberFormatException entails an implicit precondition. The concretizing step is the refactoring that introduces the typed variable.

Wait, but isn’t the problem with using Strings and primitive objects everywhere that they lack abstraction? Yes. They indicate that the code lacks an explicit model, or in other words, abstractions. They also indicate the code lacks concretizations – specifics from the problem domain that make it a well-focused machine. (Lacking both abstraction and concretization indicates ontological slime, a wonderful term from William Wimsatt, and perhaps the topic of another post.)

For a multi-line example of primitive concretization, consider this refactoring available when going from Java 1 to 5:

Iterator expenseIter = expenses.iterator();
while (expenseIter.hasNext()){
  Expense expense = (Expense)expenseIter.next();
  sum += expense.getExpenseValue();
}

to

for (Expense expense: expenses){
  sum += expense.getExpenseValue();
}

This mirrors the evolution of Java itself as a technical object and iteration as a technical concept. I’ve written about Simondon and the history of looping at more length elsewhere. Specialization and reduction are near-synonyms more frequently used in programming, but because of the clearer relationship to abstraction, and the connection to Simondon, I stick with concretization here, at the cost of a few more syllables. (Reification is a different concept, in my opinion.)

Interleaving Abstraction and Concretization

The adjunction of a supplementary structure is not a real progress for the technical object unless that structure is concretely incorporated into the ensemble of the dynamic system of its operation. – Simondon, Mode of Existence of Technical Objects, Mellamphy trans.

Design improvements often include both abstracting and concretizing steps. The feeling is of abstraction clearing space and concretization then making better use of it.

Michael Feathers’ use of characterization tests is an example of starting a design process with concretization.

    @Test
    public void removesTextBetweenAngleBracketPairs() {
        assertEquals("", Pattern.formatText(""));
    }

Characterization tests stabilize the function of the machine by pinning down very specific behaviors in the form of facts. This then allows a round of refactorings and rewrites. The immediate next step would often be abstracting refactorings such as Extract Method and Extract Class (naming a clump of things introduces an abstraction and an indirection).

Arlo Belshee’s Naming Is A Process also interleaves abstracting and concretizing steps.

Missing to Nonsense – Abstraction
Nonsense to Honest – Concretization
Honest to Honest and Complete – Concretization
Honest and Complete to Does the Right Thing – Abstraction
Does the Right Thing to Intent – Concretization
Intent to Domain Abstraction – Abstraction

A number of these steps, especially in the later half, themselves consist of interleaved abstracting and concretizing sub-steps. Eg in Honest and Complete:

1/ Use Introduce Parameter Object. Select just the one parameter you want to encapsulate. Name the class Foo and the parameter self. (Abstraction)
2/ Use Convert To Instance Method on the static. Select the parameter you just introduced. (Abstraction)
3/ Improve the class name (Foo) to at least the Honest level. (Concretization)
4/ Go to the caller of the method. Select the creation of the new type. Introduce parameter to push it up to the caller’s caller. (Abstraction)
5/ Convert any other uses of the parameter you are encapsulating to use the field off the new class. (Concretization)

Belshee’s process, using names as the signposts for improving code, is a wonderful combination of practical walkthrough and a theory of programming. It even seems to put living flesh on my skeletal wish for Name Oriented Software Development, though, eg, stronger tool and language support for consistent dictionaries are needed to realize the full vision.

Executable Theory

This kind of divergence of functional aims is a residue of abstract design in the technical object, and the progress of a technical object is definable in terms of the progressive reduction of this margin between functions in plurivalent structures. – Simondon, ibid

Every abstraction, even one as small as an extracted method, is also a theory. These little theories then need to be applied and refined to ensure a coherent system. What Simondon saw in the evolution of mechanical engines and other industrial era machines, we can observe at smaller scale and higher frequency when engineering in our more plastic computational material.

Simondon describes machines as becoming more concrete over time, finally reaching a highly focused state where each part cleanly supports the functions of others in an overall system. He also states that the introduction of a new theory is the invention of a new machine. So perhaps he would disagree that the process is cyclical.

We can, perhaps, reconcile this if we think of each software function or class as a small widget in a larger system. In this sense of the widget = machine = function, every new method is a new Simondonian machine. This also suggests that software rarely progresses to the refined machines he describes, but is more usually an assembly of semi-refined widgets. Which sounds about right.

Once you realise abstraction and concretization are complementary, anti-parallel processes, you start noticing it everywhere. I suspect casual design phrases like “nice abstraction” are actually misleading. Ohm’s Law is a nice abstraction; modern chips that rely on parasitic capacitance in a material context of silicon are well-built machines. In working software, a nice abstraction is also a nice concretization: a well-formed widget within a coherent machine.

All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections. – David Wheeler

Symbiotic Design

/ Adam / Leave a comment

Do we build code, or grow it? I was fortunate enough to attend a Michael Feathers workshop called Symbiotic Design earlier in the year, organized by the good people at Agile Singapore, where he is ploughing biological and psychological sources for ideas on how to manage codebases. There’s also some links to Naur and Simondon’s ideas on technical objects and programming that weren’t in the workshop but are meanderings of mine.

Ernst Haeckel - Trachomedusae, 1904 (wiki commons)

Ernst Haeckel – Trachomedusae, 1904 (wiki commons)

Feathers literally wrote the book on legacy code, and he’s worked extensively on techniques for improving the design of code at the line of code level. Other days in the week focused on those How techniques; this session was about why codebases change the way they do (ie often decaying), and techniques for managing the structures of a large codebase. He was pretty clear these ideas were still a work in progress for him, but they are already pretty rich sources of inspiration.

I found the workshop flowed from two organizing concepts: that a codebase is an organic-like system that needs conscious gardening, and Melvin Conway’s observation that the communication structure of an organization determines the shape of the systems its people design and maintain (Conway’s Law). The codebase and the organization are the symbionts of the workshop title. Some slides from an earlier session give the general flavour.

Feathers has used biological metaphors before, like in the intro to Working Effectively With Legacy Code:

You can start to grow areas of very good high-quality code in legacy code bases, but don’t be surprised if some of the steps you take to make changes involve making some code slightly uglier. This work is like surgery. We have to make incisions, and we have to move through the guts and suspend some aesthetic judgment. Could this patient’s major organs and viscera be better than they are? Yes. So do we just forget about his immediate problem, sew him up again, and tell him to eat right and train for a marathon? We could, but what we really need to do is take the patient as he is, fix what’s wrong, and move him to a healthier state.

The symbiotic design perspective sheds light on arguments like feature teams versus component teams. Feature teams are a new best practice, and for good reasons – they eliminate queuing between teams, work against narrow specialization, and promote a user or whole-product view over a component view. They do this by establishing the codebase as a commons shared by many feature teams. So one great question raised is “how large can the commons of a healthy codebase be?” Eg there is a well known economic effect of the tragedy of the commons, and a complex history of the enclosure movement behind it. I found it easy to think of examples from my work where I had seen changes made in an essentially extractive or short-term way that degraded a common codebase. How might this relate to human social dynamics, effects like Dunbar’s number? Presumably it takes a village to raise a codebase.

Feathers didn’t pretend to have precise answers when as a profession we are just starting to ask these questions, but he did say he thought it could vary wildly based on the context of a particular project. In fact that particularity and skepticism of top down solutions kept coming up as part of his approach in general, and it definitely appeals to my own anti-high-modernist tendency. I think of it in terms of the developers’ theory of the codebase, because as Naur said, programming is theory building. How large a codebase can you have a deep understanding of? Beyond that point is where risks of hacks are high, and people need help to navigate and design in a healthy way.

((You could, perhaps, view Conway’s Law through the lens of Michel Foucault, also writing around 1968: the communication lines of the organization become a historical a priori for the system it produces, so developers promulgate that structure without discussing it explicitly. That discussion deserves space of its own.))

Coming back to feature teams, not because the whole workshop was about that, but because it’s a great example, if you accept an organizational limit on codebase size, this makes feature/component teams a spectrum, not good vs evil. You might even, Feathers suggests, strategically create a component team, to help create an architectural boundary. After all, you are inevitably going to impact systems with your organizational design. You may as well do it consciously.

A discussion point was a recent reaction to all of these dynamics, the microservices approach, of radically shrinking the size of system codebases, multiplying their number and decentralizing their governance. If one component needs changes, the cost of understanding it is not large, and you can, according to proponents, just rewrite it. The organizational complement of this is Fred George’s programmer anarchy (video). At first listen, it sounds like a senior manager read the old Politics Oriented Software Development article and then went nuts with an organizational machete. I suspect that where that can work, it probably works pretty well, and where it can’t, you get mediocre programmers rewriting stuff for kicks while the business paying them drowns in a pool of its own blood.

Another architectural approach discussed was following an explicitly evolutionary approach of progressively splitting a codebase as it grew. This is a technique Feathers has used in anger, with the obvious biological metaphors being cell meiosis and mitosis, or jellyfish reproduction.

The focus on codebases and the teams who work on them brings me back to Gilbert Simondon’s idea of the “theatre of reciprocal causality”. Simondon notes that technical objects’ design improvements have to be imagined as if from the future. They don’t evolve in a pure Darwinian sense of random mutations being winnowed down by environmental survival. Instead, when they improve, especially when they improve by simplification and improved interaction of their components, they do so by steps towards a potential future design, which after the steps are executed, they become. This is described in the somewhat mindbending terms of the potential shape of the future design exerting a reverse causal influence on the present: hence the components interact in a “theatre of reciprocal causality”.

This is exactly what programmers do when they refactor legacy code. Maybe you see some copy-pasted boilerplate in four or five places in a class. So you extract it as a method, add some unit tests, and clean up the original callers. You delete some commented out code. Then you notice that the new method is dealing with a concept you’ve seen somewhere else in the codebase. There’s a shared concept there, maybe an existing class, or maybe a new class that needs to exist, that will tie the different parts of the system together better.

That’s the theatre of reciprocal causality. The future class calling itself into existence.

So, given the symbiosis between organization and codebase, the question is, who and what is in the theatre? Which components and which people? Those are the components that have the chance to evolve together into improved forms. If it gets too large, it’s a stadium where no one knows what’s going on, one team is filming a reality TV show about teddy bears and another one is trying to stage a production of The Monkey King Wreaks Havoc In Heaven. One of the things I’ve seen with making the theatre very small, like some sort of Edinburgh Fringe Festival production with an audience of two in the back of an old Ford Cortina, is you keep that component understandable, but cut off its chance at technical evolution and improvement and consolidation. I’m not sure how that works with microservices. Perhaps the evolution happens through other channels: feature teams working on both sides of a service API, or on opportunistically shared libraries. Or perhaps teams in developer anarchy rewrite so fast they can discard technical evolution. Breeding is such a drag when drivethru immaculate conception is available at bargain basement prices.

Iteration

/ Adam / Leave a comment

Abstraction is a concept familiar to programmers, and a term in common use. Abstraction is often discussed as a quality of code, but it can also describe a process of technology changing in a particular way over time. Gilbert Simondon, among others, offers the term concretization to describe a kind of anti-parallel process where technology components become more specific and effective over time, as designs evolve.

That introduction is pretty abstract. Examples can be seen in the changing design of loops.

Continue reading →