This argument always strikes me as a cop out. Software is bad due to historical accidents, cultural factors, and short term economic incentives, not irreducible mathematical complexity.
Or even spend any more time talking to you. Despite being a stakeholder, they may not care about failure so long as they don’t get the blame.
In this case your project will fail regardless. You just won’t have wasted person-centuries of development time.
I am waiting for the application of the proposed solutions for software complexity. I have been for a long time. Nobody really came up with anything, even though many have complained about it.
We just have code smells (like the code makes your tummy hurt?) and we've got "best practices" with zero explanation where they came from or why they're supposed to work.
This definition means that complexity is completely dependent on the individual. And also probably on how distracted they are and how much sleep they had and how much coffee they've consumed.
I can't accept a definition that makes code complexity go up if the engineer looking at it had to stay up late with a sick toddler. Or that makes a bunch of spaghetti obfuscated code go down because the engineer who obfuscated it put in this one neat trick that only they know about.
Also "the ways that code interacts with the rest of the universe" pretty much pegs all software at a complexity of infinity (got to take into account those gamma rays flipping bits).
Not particularly useful beyond selling an Excell spreadsheet to management that's going to give an "accurate estimation" because this time is going to be different.
Isn't this exactly how it works though? Many things look hopelessly complex until you gain additional knowledge about adjacent concepts.
Consider how an elegant piece of Haskell code looks to an outsider who isn't yet proficient with the type system. Consider how difficult it is to make sense of call/cc the first time you encounter the concept of continuations, even though the underlying principle is incredibly simple. Consider how apparently difficult it is for many seasoned developers to adjust to the Rust borrow checker.
It's almost like you need a "frame of reference" for judging complexity, analogous to physical systems. The velocity of an object is entirely dependent on the observer ...
However, intercal is designed to be purposefully incomprehensible. You can make it (objectively) incrementally less complex by removing the "please" rule, for example. Similarly you can make it objectively more complex (in a way that nobody can get used to) by randomly choosing a number at compile time and then requiring every file to have a "please" on that line.
Familiarity can make complexity easier to deal with but there exists objective complexity that (all things being equal) will make things easier to deal with if it were addressed.
I can see where the notion of scoring overall complexity can be a useful cognitive tool when working alongside people with similar backgrounds to yourself but I don't think there's anything objective about it at all. In fact, I don't think that an objective measure can exist in the general sense.
Note that all I'm arguing here is that any useful software complexity metric will inevitably exhibit a dependence on the individual. I agree that intentional obfuscation adds complexity in an objective sense but would argue that there's no objective way to quantify how much it adds and that any such score will inevitably vary between observers.
I think Code Golf is a relevant example here. Programs of minimal size whose textual representation often looks almost like line noise. They are simple and elegant in the sense that they are small; the meaning per character has been maximized to the best of the author's ability. However, they are also highly complex in the sense that the typical human will find them incredibly difficult to make sense of.
Which is quite impossible. This kind of understanding is a bunch of mental levers, trying to Nicolas Cage every possible scenario to a piece of code.
That's why we have ideas such as clean code and TDD - to ensure that we don't have to fully understand the form and function of a piece of code. Instead, we can be humans, worry about the general design, and allow machines to validate it.
https://www.amazon.com/Refactoring-Improving-Design-Existing...
Charles Perrow’s model in his book Normal Accidents is Interactions vs. Coupling, though that seems overly simplistic.
Extending that a bit:
https://joindiaspora.com/posts/97208f300fc4013901a3002590d8e...
I'm not sure that I understand and/or agree with this link. However, I've written and talked about this topic in the past and the response that I've gotten is usually some variation of, "Cool, but I'm not sure that I get it."
It feels kind of like the blind men describing the elephant. People are grasping at something that's probably real, but it's so big that it's going to take a long time before we finally manage to pin down anything concrete. The effort has to start somewhere though.
Other interesting occurrences:
http://curtclifton.net/papers/MoseleyMarks06a.pdf (out of the tar pit) https://www.sonarsource.com/docs/CognitiveComplexity.pdf (semantic compression) https://www.progsbase.com/blog/flow-charts-of-programming-la...
I'm not sure any attempt I've seen covers everything, but I think it's interesting that people keep trying to describe something that looks suspiciously similar.
And "short term economic incentives" is just a dismissive way to say that having working software now is a hell of a lot more useful than perfect software at an unknowable time in the future.
One could imagine a "bloat free" OS that eliminates the overhead of the paging MMU and has rationalized APIs and does everything differently.
But you need a userspace and you're going to want to run (say) vi as a text editor and you need a shell so you get zsh to run, and you want "grep" and "awk", etc.
So you have to emulate the old API and in the process of doing that all the old bloat goes back in...
We are resigned to the feeling that ‘it’s never gonna get fixed’. It’s not a good way to be, and to see this worldview permeate into objective areas of life is even more depressing.
Misanthropy kind of absolves humanity of it’s nature. What I don’t like to see in software is that type of absolution for code we know is obviously not pragmatic. It’s a tough debate because often the perpetrators of complex abstraction layers don’t believe it’s bad (any number of us could have been the guilty party at some point or another):
I think we should still try to be optimistic about openly debating complexity, or else we risk allowing misanthropic perceptions to enter this realm too - ‘people just suck at programming, so be it’.
But one can hold both of the opposing views of what the upscussion is talking about in human nature and misanthropy. Good architecture encourages the right decisions. So we can both accept that human nature will "come out" and also strive to help our fellow humans make the best possible decisions in light of that.
Anything else is not being true to ourselves and the situation.
There is intrinsic irreducible complexity that comes with many problems and there's no way to fix that. Software solutions also cannot scale linearly with the complexity of the problem.
In fact, it's provably outright impossible to even calculate the complexity of a problem in general, let alone find the optimal (as in least complex) solution (see Komolgorov complexity).