3 ms·

This assumes that complex software problems are decomposable into discrete components defined and analyzable solely by their public interfaces. Complex software

This assumes that complex software problems are decomposable into discrete components defined and analyzable solely by their public interfaces. Complex software frequently cannot be modeled in this way -- it is what makes the software "complex". In reality, components have complex interactions far outside of what is captured in the component interfaces (see also: Hyrum's Law). Surfacing these implicit interactions at the component interface level just creates insanely complex interface definitions, moving the complexity somewhere else. To tie it to something concrete, just about everyone thinks C++ template metaprogramming is unreasonably difficult to reason about even aside from the syntax, but it exists to be extremely powerful at precisely expressing behavioral contracts of a software component that are difficult to do in other languages. Even then, it barely scratches the surface of what would be useful to express for the interaction of those components to be "simple". The number of design parameters of a component that really matter in various contexts are astronomical. No one can deal with reasoning about that many component traits in practice, so the software engineers simply hide most of them -- the complexity is still there and will manifest in unexpected ways because it is not visible at the interface. All systems engineering is complex for this reason. Any non-trivial software system has to be reasoned about as a monolith at some level to correctly address complexity, which creates an unavoidable cognitive load. This isn't a software engineering problem, it is a systems-thinking problem. In chemical engineering, for example, there are often complex system design problems that cannot be adequately addressed by decomposing them into a sequence of sub-problems, all that does is hide major complexity at the interface of the sub-problems.

bigbonch 4y ago
There are many embellished, hand wavy statements in this comment. Could you give real world examples of: * "In reality, components have complex interactions far outside of what is captured in the component interfaces" * How template metaprogramming "precisely express[es] behavioral contracts... that are difficult to do in other languages" I think you contradict your poetry with "Any non-trivial software system has to be reasoned about as a monolith at some level to correctly address complexity". If _any_ non-trivial software system _can_ be reasoned about as a monolith then it is true there exists some model with sufficient simplicity that there are well-defined discrete components.
- gmfawcett 4y ago
  That's a nice belief, but you've given no rational argument for it. Consider a monolith implemented as a single, unstructured function: 200,000 lines of unstructured code, written by a goto-loving maniac. Demonstrate why some equivalent model with well-defined, discrete components must exist.
- jandrewrogers 4y ago
  You are misunderstanding the problem. Any systems problem can be decomposed into a discrete problems with sufficient fidelity to satisfy a quality requirement. The problem is that the number of discrete components in the model required to provide sufficient fidelity to minimize complexity can frequently number in the millions. No human can reason about that. All you've done is move the abstractions around. Many physical engineering systems have this property; it is in fact a major use of high-end compute resources. Traditional engineering disciplines that routinely have this problem of non-decomposability actually treat it as a systems problem (or a supercomputing problem), they don't shy away from it simply because the cognitive complexity is difficult. They convert the entire system into a set of simultaneous equations that needs to be solved for. In software, we would call this designing a monolith, but the reason it is done in traditional engineering disciplines is that you can't wish away the fundamental nature of the problem. In software, because it is not a physical engineering discipline, you can pretend that this issue doesn't exist, for a while at least. Systems complexity is intrinsic, there is no trivial reduction. If there was engineers of all types would serve little purpose. Not coincidentally, the engineers that command the highest salaries are those that have the cognitive capacity to reason about the most complex systems dynamics, the dynamics that can't be decomposed into independent sub-problems before understanding the behavior of the entire system.

bigbonch 4y ago

There are many embellished, hand wavy statements in this comment. Could you give real world examples of: * "In reality, components have complex interactions far outside of what is captured in the component interfaces" * How template metaprogramming "precisely express[es] behavioral contracts... that are difficult to do in other languages" I think you contradict your poetry with "Any non-trivial software system has to be reasoned about as a monolith at some level to correctly address complexity". If _any_ non-trivial software system _can_ be reasoned about as a monolith then it is true there exists some model with sufficient simplicity that there are well-defined discrete components.

gmfawcett 4y ago
That's a nice belief, but you've given no rational argument for it. Consider a monolith implemented as a single, unstructured function: 200,000 lines of unstructured code, written by a goto-loving maniac. Demonstrate why some equivalent model with well-defined, discrete components must exist.
jandrewrogers 4y ago
You are misunderstanding the problem. Any systems problem can be decomposed into a discrete problems with sufficient fidelity to satisfy a quality requirement. The problem is that the number of discrete components in the model required to provide sufficient fidelity to minimize complexity can frequently number in the millions. No human can reason about that. All you've done is move the abstractions around. Many physical engineering systems have this property; it is in fact a major use of high-end compute resources. Traditional engineering disciplines that routinely have this problem of non-decomposability actually treat it as a systems problem (or a supercomputing problem), they don't shy away from it simply because the cognitive complexity is difficult. They convert the entire system into a set of simultaneous equations that needs to be solved for. In software, we would call this designing a monolith, but the reason it is done in traditional engineering disciplines is that you can't wish away the fundamental nature of the problem. In software, because it is not a physical engineering discipline, you can pretend that this issue doesn't exist, for a while at least. Systems complexity is intrinsic, there is no trivial reduction. If there was engineers of all types would serve little purpose. Not coincidentally, the engineers that command the highest salaries are those that have the cognitive capacity to reason about the most complex systems dynamics, the dynamics that can't be decomposed into independent sub-problems before understanding the behavior of the entire system.