Software has its own Gresham's Law

'Basically the only requirement is that "good" solutions are more liquid than "bad" ones' - this could be used as a criteria to identify both good and bad stuff

Interesting that nobody have brought up the topic of computer viruses yet. People tend to grasp the evolutionary parallel better with parasitic software than with symbiotic one.

It doesn't require that replaceable components are always replaced with non-replaceable ones. The point is that over time, a replaceable component is likely to be swapped out multiple times, until, probably by accident, it is replaced with a component that is no easily replaceable, as which point it becomes stuck (e.g. glue code is written specifically to interface with that component and would be difficult to rewrite for a replacement).

In mathematical terms, you can imagine it as a Markov chain describing the component currently slotted in, where non-replaceable components are the absorbing states.

Yes, without government coercion, it's simply Thier's law: good money drives out bad. So if software tends to degrade over time, what's playing the perverse role of preventing people from switching to better modules/software?

Speaking through my long white beard, I would say this is not trivially true. If we follow what the article says and say this is about survival in a particular niche, then yes, Programmers who are good at a specific job will eventually be replaced at that job, while programmers who are terrible at that job but not obviously so will tend to stay in that job.

Thus, if you want to maintain the same piece of the same legacy application indefinitely, be terrible at at. Whereas, if you are good, do the job and move on. Whether that means moving upwards, or to new pastures, or embracing new technologies, being good means constantly renewing yourself.

The caution in all of this is that if you fail to be good, not only will you be irreplaceable, but you will also be immobile. So, either polish your skills on a regular basis, or polish your Swingline stapler.

It's more complicated than that. People who suck at their job can also be more replaceable, and people who are great at their job can be less so.

To me what's more interesting is sociological studies of business promotion. I took some sociology courses at Cornell, and though I don't remember the exact studies, I understood the gist to look like this: businesses generally can be understood to promote like this:

First, promote whoever is (roughly) more senior: your new IT head is more likely the Alice, the Senior Developer who has been here for 5 years than Bob, Carol, or Dennis, the Developers who have each been here for 1 or 2.

If those are equal (e.g. Alice declines the promotion or reveals that she's also about to accept a different job), promote whoever is more replaceable. Bob, who is an amazing developer who has been stuck maintaining a big hairball system at the behest of a fussy client who constantly asks him to make little tweaks, is totally out of the running, even if he's the most qualified in other respects: we can't promote him because nobody can easily take over his old job.

Third, promote whoever "feels" better. This is a complex agglomeration of personal marketing, actual leadership instincts, and even factors like preferring someone who is worse at their job because the other person seems to have "found their niche". Carol, who is a "rockstar developer" who can pull together an awesome prototype in a week, is totally helpless if Dennis, a more hum-drum average programmer type, has higher-visibility projects, a good rapport with others on the management team, and who fought unsuccessfully but valiantly that one time to keep that key client. He's way less talented than Carol, but he "feels" more right for the job.

Another detail from that sociology course was studies of social power. People who were viewed as "powerful" in buisnesses were usually not the best-connected, but the most strategically-connected. That is, if your social graph can be mostly factored into two or three subgraphs which are well-connected internally but not well connected to each other (e.g. different departments that don't talk much to each other), then within a subgraph, the node which connects to the other subgraphs will feel like the most "powerful". Social power is about connecting subnets. The person with the most social power in IT is not the person who connects best with everyone in IT, but the one who talks regularly with people in Client Services, Marketing, and Accounting: they're "powerful" because someone comes to them saying, "hey, I have an accounting problem with my latest paycheck, do you know who I can talk to about that?" and they can immediately say, "Well, you normally want Erica but she said she's swamped this week, let me see if Flynn will look into it for you, he owes me a favor anyway since I solved a database problem for him."

Anything that changes continually with a bias toward preserving existing structure ends up looking like biology in some way.

When people add to existing methods rather than creating new methods, or add to existing classes rather creating new classes we end up with that organic feel. Fruit starts green, grows ripe, and ends rotten.

The fact we need to face is that this is what people do naturally. It's not an accident. It's more like behavioral economic incentive.

Any constraint not imposed by a compiler is a degree-of-freedom that will drive a system toward complexity. It takes extraordinary effort and discipline to avoid this, especially over the long term. (One way of thinking about what architecture is is defining what allowed DoFs are on a system, so if you need to add a field to a form or implement some feature, the architecture is the thing that maps to individual concrete artifacts.)

That's a great point but the amount of analysis seems huge. Also what to quantify exactly? (and the criteria is different per programming paradigm)

Thank you. You beat me with that one :)