OP here, much of this paper resonates around the knowledge we need to build a system, lot of this is like the understanding of business rules, is the context we need to build a working software in the first place.
The problem is that knowledge is mostly "tacit", and tends to grow as the software evolves. For example, several development tasks are normally completed not only based on the documented user stories, but they also carry the context from meetings or discussions that aren't documented.
When you lose the original authors of the program, it becomes very difficult to rebuild the necessary context to understand how the system works - tasks like adding new features or modifying existing behavior becomes very hard. Also in the "The Metaphor as a Theory" part, much of the work is a shared knowledge between the developers, when you have several programmers working in parallel as fast as they can, the design of the program can become highly incoherent.
Nowdays we have practices like testing which could be a really helpful companion when it comes to understanding how the system works and the expected behavior of it's parts, which can be treated as a documentation, also we have code reviews that can guarantee that any addition to the system is consistent according to the system's design if is done right.
But still, this dependency of the context it's a very hard problem to resolve.
> The problem is that knowledge is mostly "tacit", and tends to grow as the software evolves
Totally agreed. I agree that the missing codification is the context that was needed at the genesis of the program -- the context necessary to understand it holistically.
Seems to me a valid way of understanding this problem is that there is a missing piece of documentation. It's generally well documented where/what the starting point product/business idea is as well as where/what the end point code is, but how point B was derived from point A is oftentimes not well documented. This method of derivation highly informs the structure of the result, and is a lossy conversion. It can be thought of as the "spirit" of a program/an org's engineering department (what happens in between the product ideas you can see going in and the lines of code output you can see coming out).
If that part, and the methods and techniques by which an org maps and translates an idea from the domain of business into the domain of code, is codified and documented and evolved alongside the programs the org produces then it may help.
The problem is that knowledge is mostly "tacit", and tends to grow as the software evolves. For example, several development tasks are normally completed not only based on the documented user stories, but they also carry the context from meetings or discussions that aren't documented.
When you lose the original authors of the program, it becomes very difficult to rebuild the necessary context to understand how the system works - tasks like adding new features or modifying existing behavior becomes very hard. Also in the "The Metaphor as a Theory" part, much of the work is a shared knowledge between the developers, when you have several programmers working in parallel as fast as they can, the design of the program can become highly incoherent.
Nowdays we have practices like testing which could be a really helpful companion when it comes to understanding how the system works and the expected behavior of it's parts, which can be treated as a documentation, also we have code reviews that can guarantee that any addition to the system is consistent according to the system's design if is done right.
But still, this dependency of the context it's a very hard problem to resolve.