Cheap Code -> Expensive Collaboration
In my day job, I do a lot of simulations of various types (modifications to production, parameter sweeps, new ideas, etc.), and so do my colleagues. These simulations used to produce a set of common artefacts and reports that would form the cornerstone of discussion in our research meetings. In some respects this was great; everyone knew what each plot meant, and therefore there wasn't much cognitive overhead before you could understand what was the 'new' bit of the idea.
However, this obviously came with a cost - the simulator, which started as a relatively simple bit of orchestration code, began to grow lumps. People wanted to add features, and although most of these stayed on research branches, over time they did leak into production. Mostly this is optional argument lists growing and the like, but there was definitely the sense among some members of the team that this setup was mistake-prone / a mistake in general. Now, historically, people would basically just have to learn what the arguments mean or propose refactors to simplify the tool (which admittedly is pretty annoying if you just want to fire away a load of narrow sims as simply as possible before running out the door for your train), but I think this actually represents a necessary part of collaboration. By getting comfortable with and investing a bit of intellectual labour in understanding your colleagues' research questions and motivations (e.g. why does xxx even need this feature???) you not only respect each other more, but also maybe understand different aspects of the problem you're trying to solve together.
Now though, we have had at least 4 new frameworks spring to life in the last 6 months, mostly doing the same sort of thing, but each with a style suited to the author's taste (functional, object based, etc). People are pretty happy with their own tooling and mostly just use it. We think they are 'close enough' in equivalence, but obviously checking this sort of thing is a totally new kind of tech debt. I don't know if this is a parochial problem for my team, but I suspect not. In any case I'm sure these 'turbo silos' are going to become an increasing feature of our industry in the coming years and I don't know what I think about it.
My initial feeling is that recreating formerly common code in your own image is basically just a form of procrastination, and indicative of an organisational smell. It is not hard to see that a research culture that likes to 'move fast and ship things' or whatever, is going to incentivise people to churn out a shiny new framework rather than helping maintain existing infrastructure. Fundamentally, it was always harder mentally to understand code you didn't write than make your own new thing, and this is extremely true now. The counterargument to this is that maybe one of these new frameworks is going to revolutionise the way everyone thinks about the problem and then shepherds in a new wave of progress, but I don't think so. Fundamentally, once people get into the habit of not having to read / wrestle much with other people's code, I question whether their ability to engage with other people's ideas will decay as well.
If there is a solution to this, I think it stems from us all acknowledging that code is commoditised, and churning out large quantities of it for your own use and wrapping it up as a new framework isn't value additive. Does it involve meetings where 3-5 developers actually collaborate in real time and whip Claude / Codex? I don't know, but maybe moving to this 'hyper collaboration' could at least help reinstill a sense of ownership over the common code. In any case, I think the way we work with each other has changed forever, and we need to address it.