First two paragraphs of 18th of The Eighteenth Brumaire of Louis Bonaparte is one of the most if not the most insightful works of sociology.
Hegel remarks somewhere[*] that all great world-historic facts and personages appear, so to speak, twice. He forgot to add: the first time as tragedy, the second time as farce. Caussidière for Danton, Louis Blanc for Robespierre, the Montagne of 1848 to 1851[66] for the Montagne of 1793 to 1795, the nephew for the uncle. And the same caricature occurs in the circumstances of the second edition of the Eighteenth Brumaire.
Men make their own history, but they do not make it as they please; they do not make it under self-selected circumstances, but under circumstances existing already, given and transmitted from the past. The tradition of all dead generations weighs like a nightmare on the brains of the living. And just as they seem to be occupied with revolutionizing themselves and things, creating something that did not exist before, precisely in such epochs of revolutionary crisis they anxiously conjure up the spirits of the past to their service, borrowing from them names, battle slogans, and costumes in order to present this new scene in world history in time-honored disguise and borrowed language. Thus Luther put on the mask of the Apostle Paul, the Revolution of 1789-1814 draped itself alternately in the guise of the Roman Republic and the Roman Empire, and the Revolution of 1848 knew nothing better to do than to parody, now 1789, now the revolutionary tradition of 1793-95. In like manner, the beginner who has learned a new language always translates it back into his mother tongue, but he assimilates the spirit of the new language and expresses himself freely in it only when he moves in it without recalling the old and when he forgets his native tongue.
Here Karl Marx also humanistically describes the root problem of production of processes in general. The problem of the cumulative error. While Marx is describing the production of history that is a productive force, it is also in a class of meta-productive forces. These are productive forces that do not directly produce material goods but affect the productive forces that do create physical goods and services.
This is literally the same metaphor as tech-debt. Software has many parallels because the production of software is also a meta-productive force. It produces an immaterial good that is productive force in itself and produces other immaterial and material goods. Tech-debt is the effect of inefficient cycles, that weighs on future cycles.
This is similar to the educational concept of Wittigenstien's ladder or lying to children, because learning itself is a meta productive force. In essence as a productive force, learning is cyclical. In order to understand how atoms function, we teach children models that are technically incorrect such as the Bohr model so they can understand approximations closer and closer to the truth. These are all productive cycles that compound on each-other.
In all these cycles the most important thing is that each future cycle must trend more strongly in the positive direction (a better understanding, better materialist outcomes, software that is cheaper to build maintain and is more resilient), rather than accumulating errors, which will eventually self-reinforce to middling and negative results and eventually collapse.
These cycles represent real risk in the real world. For example one of the most difficult things about the way we develop technology is that its not deterministic. The classic black swan scenario of solar flares causing a strong EMP would result in chaos. This is not just because would have to rebuild everything. The simple reason fact is we cannot "rebuild" the world ex nihilio because we don't have clear knowledge of certain steps along the way. Sure we could figure it out, but that's a different process. That's the process of technological discovery, not the process of applying technology.
You can think of it as rebuilding a neighborhood being hit by a bomb. The neighborhood is gone and we don't have floor plans of some of the key buildings. But it's actually worse than that. We don't have plans to the buildings that lead to the creation of those buildings. We don't have a university, but to build a university we need a foundry, we need a printing press, we need a quarry, we need a brick yard, etc. We don't have some of those, or some of the inputs to some of those. It's actually more complex than that because each of these "functions" also scales and has dependencies at different levels of scale. So we might be able to build a brick yard, but that brick yard won't be able to produce bricks that meet modern specifications until we build a smaller university to research brick making.
I literally think about these daily during the course of my software job:
- the first time as tragedy, the second time as farce
- Men make their own history, but they do not make it as they please
- The tradition of all dead generations weighs like a nightmare on the brains of the living.
There was a period of time where I played nothing but Dark Souls 1 and 3 (same theme) and thought about these.
You're misusing terms here and I don't really want to nitpick because I've also been fast and loose, but under Marxist analysis the combination of productive forces ( tools and labor) with the relations of production (relationships between individuals) create the mode of production (capitalism). They do not create production itself.
I mention this only because it aligns with my point that these concepts are more general than the actual technical work and decision making within the productive process itself, which is what I am trying to describe. It's a level of specificity that I've been badly trying to explain:
To the side of that:
Our mode of production, capitalism, has an impact on the tools I use by their availability, their market dynamics, and cost. However it does not actually force my hand to choose one over the other, and it does not take away my agency in fighting for that choice. It merely creates an incentive for the system to override that, but remember kids "code is king" is a weapon for just these types of times if you can wield it politically. Given my position on most of the teams I've been on, and my autism I'm usually swinging for the fences.
These conceptualizations do not heavily factor into the technical decision making within a process. They can in certain respects, for example how representatives of capital nest themselves in the middle of the process. However there are inherent technical considerations beyond the mode of production, we should always keep the relations of production in mind when working through them.
I don't expect engs that I manage to go out of their way unless they're obsessives like I am because of the relations of production and the mode of production. However I do expect them to be able to work through the technical decision making and consequences on the process of production of those decisions. That's generally within their purview.
For example: I do not expect an engineer to compensate for a delay by overworking. However I do think if they introduce a new library they have to explain why we need it, explain how it affects the stability of the system, explain how it affects how we write software, and ensure that the trade offs are not making it harder to do our jobs.
You can reify that through the relations of production, e.g. devs have a responsibility to each other not to make the work harder. However that abstracts away what "making the work harder" actually means technically speaking because that is the actual hard part and what I actually get paid for.
This is a just so story. Capitalists themselves often cannot tell what threatens "their production of surplus value." The zillion industry specific reasons do not have a clear calculus, and they do not have a clear calculus in other sectors in the real world either. This is the problem, capitalism, especially in software, is a speculative hindsight based understanding. I am talking about conceiving of production via foresight. The reason I explain process cycles is that it's very easy to point out parts of the cycles that cause waste. Whether a capitalist accepts that waste or not is irrelevant, because that's the capricious nature of of the mode of production. The capitalist themselves is a source of waste.
The job of a software architect or tech lead or any software leader is to explain these decisions and their consequences (e.g. the cycles of production) via foresight to a baby brain dullard who will then shit all over their plans anyway.
I disagree with statement solely on the fact that technical debt itself is a fuzzy concept.
Beyond that process cycles represent a real way to explain the long term viability of software production which creates a relative measure for technical debt. I am not an oracle even though I wish I was, seems like a cool job. I cannot tell if the market will "reward" us for our "brilliant idea". I can tell however that producing software in a certain way if not rectified going to lead to failure sooner rather than later under the context of the social relation.
For example if you have a capricious management or a uncertain market, there are choices that you can make in the architecture of your program that make your project more sensitive or more resilient to resourcing changes on your team. In order to figure out that path you need a framework, other than the social relation, because under the current social relation the logical conclusion is if you have a stupid boss you should just find a new one or give up until the revolution comes.
As socialists we talk a lot about the "antisocial" nature of capitalism, and this is an opportunity to fight to prevent that natural inclination. I cannot morally make that choice to say "this technical situation is management's problem", because I have people who's children depend on me making and pushing through good technical choices to minimize the risk of their parents becoming unemployed (hey look a social relation reason, however as an incredibly weak incentive this one is a personal choice). It's an inherent moral hazard of having a hand in the technical process of production.
Beyond that, absent of a market, software can still exist because it's useful. These projects still need to be architected, these trade off still need to be adjudicated not just on their technical merits but on their viability within the social relation. It's why large open source projects are run completely differently than commercial ones. The Cathedral may follow a capitalist like model, because of the similarity of the relation, but the Bazaar inherently cannot.
There are plenty of software projects out there open source and commercial that successfully resist the inherent problems within the social relation under which would lead them to sub-optimal technical choices, because the alternative is failure.
TL;DR
I fully admit this conceptualization is cope, and is irrelevant to solving the root causes of the problem of the mode of production and the social relation. However I submit that cope theory is important because I have no delusions of overthrowing the capitalist relation and I owe it to the other people who I have indirect authority over. I believe that aristocratic labor positions confer some personal responsibility and moral hazard that must be abated. Beyond that we will still need cope after the revolution. Fixes in the social relation can fix a lot but they cannot fix everything. Production has inherent negative externalities and people will always need to cope with those.
I’m curious what you think of hardware tech debt. Specs that were perfectly viable at the time, but as a result of Moore’s law and software improvements/complexity increases, are made obsolete.
Hardware can't really have "tech debt" in the same way as software. Hardware is a physical entity, each computer is a different computer, they're the same model, the same design, but they're different computers. Each installation of software is a direct copy. If we're on the same architecture and the same version, we're running the same Firefox unless something is wrong with Mozilla.
I think hardware that's outdated is bound to happen. As a hobbyist I have my own share of "outdated hardware". In reality that shit still works. I can pull an old laptop and put Fedora Silverblue on it today and it will work just fine for surfing the web, writing on forums, doing a good amount of hobbyist software stuff, etc.
And there in lies the problem, that much of the lifecycle of hardware is directly tied to software support and typically very strongly to bad commercial software. We can give people reasons to not upgrade and we'll write better software for it. Some of the best software is effectively eternal, for example I have used vim my entire professional career even when I was writing Java.
I think the biggest problems is that there's too much hardware and proprietary hardware being made now a days, and not enough hobbyists to get it basic support. For example unless the landscape changes in 6 years I will likely have no way to revive full functionality for my M1 Apple silicon.
But that's PC's, the more egregious things are smaller form factor devices. Android has been the biggest disappointment for me to be honest. What was sold as a "Linux Phone" gave you none of the technical benefits of Linux. So much small form factor stuff essentially becomes ewaste. The small amount of platforms that gain hobbyist support are extremely rare and limited. This is exacerbated by tight integration between physical devices to server side software as a service platforms.
If the libre movement was not a hollowed out husk of it's former self and the economic conditions were able to create a new set of leaders for it we would have
GPLv4 that requires you to license as GPLv4 if you use any remote procedure call regardless of medium that executes GPLv4 code.
GPLv4.1 that requires any device where GPLv4.1 code comes factory installed must have a fully documented and unlocked bootloader and/or user serviceable firmware flash functionality
GPLv5 that requires you to license as GPLv5 if you have any use of GPLv5 code in the tool/supply chain of a software for examle if FoxConn is using gnutls and you use a MacBook you're licensing as GPLv5, if you are a GPLv5 compiler, you're licensing as GPLv5
GPLv6 that makes legal to execute your landlord if they charge you rent and any GPLv6 code is used by them directly or indirectly
That would really fix some things regarding ewaste and frankly housing. TBH I think we're gonna see general computing calm the fuck down in the next 10-20 years compared to the onslaught of release cycles in the late 2000's and 2010's. The only real possible driver is going to be if games really glom on to ray tracing bullshit beyond the AAA contractually obligated messes.