Given your comment, you'd probably really enjoy Peter Naur's "Programming as Theory Building" since it's effectively heading down a similar path of thought: htt

Given your comment, you'd probably really enjoy Peter Naur's "Programming as Theory Building" since it's effectively heading down a similar path of thought: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf The gist of it is that when a small team builds a piece of software, they have a theory (or I suppose a mental model by another name) of how it exists (either the literal files on disk or a rough abstraction of the "shape" it takes) and an understanding of the strengths and weaknesses of its design. One team may share the "theory" of the program with another by adding a new team member, they learn from osmosis (not just the codebase but the insights from other members). In reality, what often happens is that a team erodes through attrition or even is entirely removed from a project. The new team who takes over it, has no theory of how the software works and has to form an entirely new theory. That theory may be mismatched to the realities of the environment it lives in (infrastructure assumptions, cultural assumptions and so on) which can make additions even worse. I suppose I imagine it like the statue of David that gets created in Spongebob only for the weird, out of place squidward nose to be tacked on it like it works but it doesn't seem quite right and you can almost point out the line. Anyway, it's an interesting conundrum since there's not really an easy way to express this concept to big bloated corporations who think they can just exchange one contracting firm for another, and not end up with a mish mash hell contraption that shits all of their customers. The natural fix might feel like having sole indies running a project where the mental model is not in jeopardy (sans being hit by a bus) although I would think it's more in the range of 10 people or so but I honestly haven't gotten far enough to test that out yet :) Additionally, you could say that documenting not just the software itself, but the assumptions held at the time would work. It probably would help but that assumes future developers will read it (some will find a rewrite the only logical course because they don't understand the project, or the language etc) while others may just be under business pressure to "move as fast as possible" which gets mistaken for "writing code" instead of understanding what came before.