As a working software engineer with experience working at a variety of scales and levels of technical debt, this mostly feels wrong to me.
One of the biggest factors in the software world is a slowly rising tide of infrastructure, which makes things cheaper to build today than they would have been to build a decade ago. Projects tend to be tied to the languages and libraries that were common at the time of their creation, which means that even if those libraries are stable and haven’t created a maintenance burden, they’re still disadvantaged relative to new projects which get the benefit of more modern tools.
Combined with frequent demand shocks, you get something that doesn’t look much like an equilibrium.
The maintainability of software also tends to be, in large part, about talent recruiting. Decade-old popular video games frequently have their maintenance handled by volunteers; a firm which wants an engineer to maintain its decade-old accounting software will have to pay a premium to get one of average quality, and probably can’t get an engineer of top quality at any price.
Possible point of confusion: equilibrium does not imply static equilibrium.
If a firm can’t find someone to maintain their COBOL accounting software, and decides to scrap the old mainframe and have someone write a new piece of software with similar functionality but on modern infra, then that’s functionally the same as replacement due to depreciation.
If that sort of thing happens regularly, then we have a dynamic equilibrium. As an analogy, consider the human body: all of our red blood cells are replaced every couple of months, yet the total number of red blood cells is in equilibrium. Replacement balances removal. Most cell types in the human body are regularly replaced this way, at varying timescales.
That’s the sort of equilibrium we’re talking about here. It’s not that the same software sticks around needing maintenance forever; it’s that software is constantly repaired or replaced, but mostly provides the same functionality.
As a working software engineer with experience working at a variety of scales and levels of technical debt, this mostly feels wrong to me.
One of the biggest factors in the software world is a slowly rising tide of infrastructure, which makes things cheaper to build today than they would have been to build a decade ago. Projects tend to be tied to the languages and libraries that were common at the time of their creation, which means that even if those libraries are stable and haven’t created a maintenance burden, they’re still disadvantaged relative to new projects which get the benefit of more modern tools.
Combined with frequent demand shocks, you get something that doesn’t look much like an equilibrium.
The maintainability of software also tends to be, in large part, about talent recruiting. Decade-old popular video games frequently have their maintenance handled by volunteers; a firm which wants an engineer to maintain its decade-old accounting software will have to pay a premium to get one of average quality, and probably can’t get an engineer of top quality at any price.
Possible point of confusion: equilibrium does not imply static equilibrium.
If a firm can’t find someone to maintain their COBOL accounting software, and decides to scrap the old mainframe and have someone write a new piece of software with similar functionality but on modern infra, then that’s functionally the same as replacement due to depreciation.
If that sort of thing happens regularly, then we have a dynamic equilibrium. As an analogy, consider the human body: all of our red blood cells are replaced every couple of months, yet the total number of red blood cells is in equilibrium. Replacement balances removal. Most cell types in the human body are regularly replaced this way, at varying timescales.
That’s the sort of equilibrium we’re talking about here. It’s not that the same software sticks around needing maintenance forever; it’s that software is constantly repaired or replaced, but mostly provides the same functionality.