Code is a Palimpsest
There’s a lot to unpack.
Is software a finished product or an ever going process?
A working program shows a solution that was appropriate at a certain point in time. That solution might be obsolete and not representative of the situation for which the program was built. It responds to needs from some other time, old needs. At least, instead of a ‘scratch it, let’s starts again’, software leaves us with the opportunity of ‘scratch it, let’s write over it’ like a palimpsest.
Every software project is like a palimpsest where every developer scratches old text, and writes on top of it their perceived new solution, creating a manuscript where a mix off styles and languages reflect different understandings of the world, different world visions.
An archeologist armed with patience and a source control tool might be able to unearth the secret history of a software artefact. Perhaps through marginalia.
Each change in the code creates new interconnections to classes and functions, producing and entanglement of meaning with every new word added to the code. The interdependencies increase. La différance becomes manifest.
A mesh grows where every node constantly has new branches pointing to it, and old branches get pruned, even though those very same branches that got deleted nested important information for understanding why that node was there in the first place. The node might end up acting like an information hub which nobody dares to delete, afraid that the cards castle might crumble. Nobody knows why that method is there, yet nobody dares to delete it.
Software development is always pathfinding without ever reaching a goal. The sign posts have changed, were moved, or forgotten. A new feature is added to the program trying to bring it one step closer to represented reality. This is futile. This will never happen, because while the branch extends from the tree to touch the river water, the trunk stayed in place, unmodified, impervious to all the changes that happened around it. When the branch finally reaches the water, the river already changed its course. Reality moved on, and never touched the real.
So software is a collection of attempts, steps that explore a labyrinth, never knowing which side to go when a new bifurcation comes, but with the certainty that the new explored path must inform upcoming travellers. Software development is laying signposts in a labyrinth. Each program is an interstate map, where some roads are highlighted telling the story of a journey, its pitfalls, its shortcuts, its ‘try this, but be careful with that’.
Signifier after signifier, we keep reading, but we can’t find the meaning of what’s written in the code. Not even a place to start, a thread to follow. Yet the software artefact runs, it seems to perform its function. But we need to change it, to improve it, yet we have no waypoint to tell us where we are, no landscape feature to place on a map and point ‘yes, we are here’. Nobody has been in these plains in years. The sands have shifted and the wind has no intentions to stop blowing. The ruins are barely visible. We can guess the shape of an older structure from a past civilisation. Software decay is real.
The oldest components of a software project aren’t necessarily the representatives of the intentions and the needs that brought it to life. Latest additions, completely foreign to the origin of the project, are what best represent its current use. The place of code that’s being worked on, day after day, scratch, delete, write over, and repeat, that’s the palimpsest we should pay attention if we want to discover what’s the theory that lets a software project move forward, but not necessarily the one that pay the bills.
The evolution of a a software artefact reflects the tastes and wills of an era. There’d be areas that wanted to cater to an enterprise reader, filled with object oriented patterns that cut through the mess and links parts forging connections that lack meaning but pushes intentions forward. A reader might no be able to understand why Class A is connected to Class B unless it’s told it just follows the need of an idea of enterprise software. But then classes fall apart, crashing onto the floor to leave a bunch of functions grouped in modules. Functions so small and so generic that only in use we can tell what meaning they carry, or produce. Functional programming tried to take over the project, so now the reader is confronted with conflicting styles. It’s time to learn where the woods end, and where the plain starts, up to where goes the snow, and where does the frozen water becomes river.
To Order, to govern,
is to begin naming;
when names proliferate
it’s time to stop.
If you know when to stop
you’re in no danger.
–Ursula Le Guin — Tao Te Ching
