Society is comparable to a software module producing business process in that it's humans working together. Agreed that in both contexts there is no such thing as "root cause" at the American society level.
Regardless, my personal choice for one would be technology.
Struggle. No one likes it, but meaning comes from pain. The story that goes "iunno, I was kinda lost so I started volunteering because some guy on an internet forum said it was a good idea" isn't compelling. You need a compelling narrative to generate the meaning you're seeking, and that is only possible in hindsight.
Don't focus on you, focus on the world. Go heads down and focus on making life better for others. Lose yourself in that, and when you look up you will have become your answer.
The codebase affects the overall outcome of a business venture built on it in the same manner that the car affects the overall outcome of a drive.
The more specific an outcome you're looking for the more factors you'll have to consider. You can loosely think of the relationship between code and companies like the code is "the matrix" and the tangible business world is "the real world". It might help to think of the code as a child being raised in the matrix.
The first product market fit stage is the hardest. Here it befits the code to be maximally extensible such that you can most effectively steer it around the market landscape and most effectively capitalize on any discoveries made. But you also need it to work decently enough to have traction. This stage is like parenting a baby that needs to decide its life mission and begin it during the first few years of its life. Its main purpose is self-discovery, but also it needs to be set up to become whatever it discovers it wants to be. Here, luck is the main name of the game.
The next stage is growth (farming the land you've staked, becoming the thing you've decided your codebase baby's life is about). Here you need less extensibility and more fidelity. You're clear on what your code needs to do, and you just need to make sure you do it well enough to last long term. But also things get more complicated at the org level. Now a team has to be built out. The codebase must now mature, and that means that it must gain a firmer grasp on its purpose (high fidelity architecture and infrastructure) and learn to interface with the world (be geared towards long-term maintainability).
After you exit that stage, you exit the startup stage entirely. Generally, if you're a businessperson and it's available to you, having good engineers (human communication skills above technical skills, understand the holistic function of engineering within the context of the rest of the company) is the best solve to this problem. They will have the vision to assess the field and the communication skills to inform you about it.
You will feel the urge to carve the unpredictability of the outcome down with measurements, metrics, and calculations but this is mostly a fool's errand. If you're doing something brand new there is no defined path and it is about pathfinding, not measuring your performance along a path. There are a ton of resources that all give opinion on the best way through this beginning patch of woods, but the true reality is that at the end of the day, getting through woods that no one has ever gotten through is something that can only be mapped in hindsight.
> 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.
> A program is a shared mental construct (he uses the word theory) that lives in the minds of the people who work on it.
Absolutely. The plain English definition for the word "program" that Google shows is (noun) "a set of related measures or activities with a particular long-term aim", (verb) "arrange according to a plan or schedule".
A software program fulfills a certain set of behaviors, serves a certain purpose, is a materialization of an idea, or otherwise is a transcription of something from a certain domain into the domain of software. The "source of truth" of what that something is is external from the program.
The knowledge domain of a programmer is therefore not only both their code and the idea it represents but the mapping in between. Both ends are easily documentable (in the narrow context of their specific domains), and it feels like this could have led to a possible convolution of what it takes to be a good programmer.
We have endless measures, philosophies, and codifications for what makes for good form when drawing back the bowstring, what release techniques make for the least disturbance to the arrow's path, what arrow shape makes for the most optimal flight, etc, but less for an archer's aiming technique. All we can do is just look to see if the target's been hit or not.
How an org "aims" the "arrow" of code towards the business target is a higher level concern than how awesome the arrow shot is or how straight it flies. If you're not controlling how you aim you lack the context to fully qualify your assessment of how arrow choice, pull/release form, or even flight path affected your result.
Codifying not only how your org builds product ideas and how it implements software, but how your org maps from one domain to the other helps mitigate knowledge siloing.
One does not stop it unless one never wants to generate any new ideas. What one stops is the imbalance and the sort of proactive procrastination it leads to, of always thinking about starting and never starting, and one does that by executing with commitment on some of the ideas.
That'll chip away at that FOMO anxiety because you'll be focused on what you're doing rather than what you're not doing. At the end of the day, it's just going to be exposure therapy to the situation where you know you're not fully capturing all possibilities that gets you over that fear. You absolutely can't predict the future so you absolutely can't ever capture all the possibilities. Perfection is the enemy of choice.
Don't make it complicated in your head, despite how loudly your gut screams at you that the risk warrants infinitely granular consideration -- just start and trust the idea(s). If you have too much anxiety, surround yourself with a support system you trust that you can rubber duck how solid the ideas are with. The rest will work itself out.
Mental flexibility. Oftentimes, people build their identities on hard and fast beliefs. These have a way of eliminating entire directions of exploration when the ingredients that cook into a decision are being gathered. Routinely refresh your deepest beliefs and your mental architecture will be much, MUCH more optimal.
Regardless, my personal choice for one would be technology.