You said above that chopping a tree is permanent, even though new trees may grow. We're of one mind there. It's worth dwelling on this distinction, because it is the essence of what I'm trying to get across.
It's not about the single tree. Trees grow and die, and every step of the process seems natural in isolation. The problem with externalities lies in the scale, in the disruption of the natural balance between competing forces.
Yes, individual rules are not directly connected to each other, and their effects are often isolated. The trouble lies in their implementation and how the interactions of implementations of different disparate rules often reduces the degrees of freedom in future rule making/management.
Say you have 100 people creating new rules or software. Each of them only cares about a few projects of rule-making, and the different projects are largely independent. If 90% of the rule-makers are making badly designed rules, the whole will gradually grow unmanageable. This story doesn't depend on what the rules are about in the real world. All we are concerned about are the implementation details. Are they implemented parsimoniously, or is the overall effect a result of two clauses combining from hundreds of pages apart? Are they easy to understand, or are they deliberately phrased in a convoluted manner to make it difficult for newcomers to join in the business of rule making? Do they follow some meta-rules consistently, or do they normalize deviance (http://lmcontheline.blogspot.com/2013/01/the-normalization-o...)? There are many such tests, and we think of them as 'design'. The design of a system is a meta-commons even if each of us has a different use case within it.
Even if you think you don't care about the rules most people follow, the rules care about you. For example, it's harder for me to find other C++ programmers to collaborate with because the pool of people who care about the same domain as me is further diluted by people who care about the same subset of C++ as me. The parts of C++ I don't use still affect my life.
Our point of difference here regards externalities. You seem to think they are pervasive, largely irreversible, and negative. I'm still not sure that externalities exist or what they would be, let alone why they would be irreversible or negative. What about positive externalities, as good practices are recognized and recommended by people to their peers?
> The trouble lies in their implementation and how the interactions of implementations of different disparate rules often reduces the degrees of freedom in future rule making/management.
Within a legal jurisdiction all laws are effectively "executing in the same scope." Thus it's obvious and natural that they could interact with each other. Less obvious that such interactions are negative, or why that would make it harder for new people to write rules. Clearly our legislators have no difficulty pumping out more and more laws every year...
In software, the implementations don't run in the same scope, unless deliberately made to do so. And again, software projects aren't compulsory or indelible. They can be deleted, ignored, replaced, etc. very easily.
I might understand if you focused on the social implications of the software, such as one person using a code base, thinking its patterns were normal, and replicating them elsewhere. But you specifically mention the implementations and that somehow interactions between implementations reduces degrees of freedom. How? Where? Within a project, or across projects?
> Say you have 100 people creating new rules or software.
This whole section mixes your analogy and your subject. Many of the statements are obvious or at least reasonable for a legal system, but not obvious for software; at least, not software as a whole. Perhaps an individual project can fit the analogy fairly well. A program may, per your analogy, have complex behavior caused by spaghetti interactions across hundreds of pages, which would make things difficult for a newcomer to change. Such things repeated as patterns across a project do constitute the "design" or architecture of it. Do such patterns exist across all of software though, when anyone can start a new project in an empty file?
I appreciate the mention of "normalizing deviance", it's potentially a useful concept for this discussion. I think you're referring to the abstract pattern of normalizing deviance from what could otherwise have been consistent meta-rules, as opposed to a specific deviance? I'm not sure where that leaves me though.
I can almost imagine the "meta-commons" you mention, but I have no confidence that it is anything other than "common sense". Yes, people have habits of thought and behavior informed by their past experiences; there's no reason they can't learn and do better on their next project though.
> Even if you think you don't care about the rules most people follow, the rules care about you. For example, it's harder for me to find other C++ programmers to collaborate with because the pool of people who care about the same domain as me is further diluted by people who care about the same subset of C++ as me. The parts of C++ I don't use still affect my life.
It sounds like you're describing a situation where "bad" approaches steal mind share, reducing the number of people available for doing "good" work. Or, in your example, the existence of other domains (rules?) creates negative externalities for you by diluting your supply of collaborators. This sounds like a zero-sum fallacy. You're assuming that those people would still be C++ programmers and that they would be compelled to share your interests for lack of options, or that the other domains poached collaborators that were rightfully yours. Generally it works the other way though; the overall size of the market is increased by the existence of competitors, who share marketing costs in a larger economy of scale. Thus, because of those other domains, people with different interests are drawn into C++ programming would otherwise wouldn't be, and maybe some of them might eventually discover yours and collaborate with you. Sadly we can't run multiple experiments to find out which universe you have more collaborators in though.
This is a helpful summary of our differences. The keystone is whether zero-sum is a good framing or not.
I think we should by default assume we're in a zero-sum regime anytime people's attention is involved. For example, think back to the SOPA/PIPA boycotts a few years ago when every website turned off for a day. That's a trick you can only pull a finite number of times before people grow jaded.
Similarly, someone is only going to try to learn programming a small number of times. And every time they think they failed increases the energy barrier for the next time. Burnout is the primary concern here, to my mind.
The same principles apply also to experienced programmers learning about new software. Burnout is the prime enemy, but the concern of minimizing burnout is on no author's mind. Nobody owns the design goal of comprehensibility of internals. Lack of ownership is the essence of an externality.
When it takes too much effort to comprehend a piece of software, people can no longer keep up with it on their time. They have to be paid to do so. That biases the playing field between insiders and users. A small number of people working on a popular piece of software can have disproportionate influence on the lives of people.
To me the argument of the previous paragraphs is ironclad. Which part do you disagree with? Is software already easy to comprehend? Is comprehension to outsiders not the #1 problem in software? Is the difficulty in comprehension not because of tragedy-of-the-commons effects?
---
I'm going to stop debating the non-software side of things, since I'm not an expert there and I don't really have any solutions to offer. I strongly feel the problems of limited attention carry over there. But it's probably easier for me to convince you of that in the realm of software. Oh wait, one final note:
> Clearly our legislators have no difficulty pumping out more and more laws every year...
Have you not met programmers talented at churning out crap? The difficulty is not in writing new laws, but in having the whole make sense. At least in software the computer enforces some basic checking. If the program crashes, that's visible to all. Contradictions in laws can fester for long periods until someone works up the resources to take a case all the way to the Supreme Court. (Why in the world don't US courts deal with counterfactuals? The whole principle of "case or controversy" (https://en.wikipedia.org/wiki/Advisory_opinion#United_States) is bound up in pre-software thinking. In my ideal world courts would be able to give feedback on bills even before they are turned into Law, and actually influence how legislators voted on them. "Have you considered this corner case?")
