> Finally, we arrive at the most specific stratum in our gradient of specificity, executable source code. Of course what makes code the most specific is not only the fact that it has to be formally strict and internally consistent in a way that no other layer must
And this is why all the other layers are useless. Modifying another layer doesn't produce useful output. Only modifying the code does.
> the rationale for why the code behaves one way and not another is often lost, or at least misplaced. And herein lies the problem: Code has far too much detail, and is much too preoccupied with its own affairs, to be the authoritative place where business decisions are made.
I've never heard anyone argue that business decisions are made in code. Business decisions are made in email or over zoom or on confluence. This is obviously bad and only occurs because the powerful people can't code. They can't make a contribution to the output that isn't just a vague exclamation that must be parsed and reconciled with the existing artifact.
The artifact is the only thing that matters. Prose on confluence isn't documentation.
The mistake in this logic is that not all code is the same. A good counterexample is separating policy and mechanism. The policy code should definitely align with external (higher level) decisions. The mechanisms also satisfy constraints that should also be known or expected but is typically more of a technical nature or more about potential capabilities fathered than immediately delivered.
> Finally, we arrive at the most specific stratum in our gradient of specificity, executable source code. Of course what makes code the most specific is not only the fact that it has to be formally strict and internally consistent in a way that no other layer must
And this is why all the other layers are useless. Modifying another layer doesn't produce useful output. Only modifying the code does.
> the rationale for why the code behaves one way and not another is often lost, or at least misplaced. And herein lies the problem: Code has far too much detail, and is much too preoccupied with its own affairs, to be the authoritative place where business decisions are made.
I've never heard anyone argue that business decisions are made in code. Business decisions are made in email or over zoom or on confluence. This is obviously bad and only occurs because the powerful people can't code. They can't make a contribution to the output that isn't just a vague exclamation that must be parsed and reconciled with the existing artifact.
The artifact is the only thing that matters. Prose on confluence isn't documentation.
The mistake in this logic is that not all code is the same. A good counterexample is separating policy and mechanism. The policy code should definitely align with external (higher level) decisions. The mechanisms also satisfy constraints that should also be known or expected but is typically more of a technical nature or more about potential capabilities fathered than immediately delivered.