[HN Gopher] Meta-analysis of three different notions of software...
___________________________________________________________________
Meta-analysis of three different notions of software complexity
Author : ingve
Score : 83 points
Date : 2025-06-14 06:54 UTC (1 days ago)
(HTM) web link (typesanitizer.com)
(TXT) w3m dump (typesanitizer.com)
| perrygeo wrote:
| I respect all three authors deeply but this is my first time
| reading Tellman's take. His idea that "simplicity is not
| intrinsic ... Simplicity is a fitness between software and our
| expectations" has a very nice ring to it.
|
| Contrast that with Hickey's notion of simplicity as an objective
| count of interleaved concerns or "folds". The quibble with this
| is, how do you delineate the concerns? Depending on your style
| and knowledge of the system, you'll get a different number. So
| it's hard to call it objective.
|
| Tellman's definition is nice because it acknowledges the
| subjectivity, and puts it front and center. IOW the "style and
| knowledge of the system" form a mental model of the software
| system. What's important is not the cardinality, OR the
| interleaving. It's the ability for that model to make good
| predictions about the software's behavior. Accurate model held in
| the minds of humans that operate it == simple software.
| motorest wrote:
| Quantifying software complexity is still largely an open
| problem. There are approaches that focus on quantifying but are
| arguably of limited use due to their disconnect with mental
| models, and there are approaches that focus on evaluating
| mental models but can't be objectively quantified. The best
| output from the latter group is that they can serve as
| guidelines on how to make simple software systems,and how to
| keep them simple.
| chii wrote:
| The hickey definition is from the POV of the engineer - the
| creation of software with simplicity. Code that is simple,
| doesn't necessarily result in a piece of software that is
| simple for the end-user.
|
| The tellman's version is for the end user - simplicity of use,
| by the user, with their existing expectation, culture and pre-
| knowledge. It's basically describing skeuomorphism in software
| (but not limited to just UI). It might be enormously
| complicated to create for the engineer, while it remains simple
| for the end-user.
| prospero wrote:
| Show me a software developer who isn't an end user for
| someone else's code.
| wtetzner wrote:
| This feels like it missed the point.
|
| Hickey's approach is relevant in how the software is
| constructed, and Tellman's is relevant to the user
| experience. Both approaches are useful for a single
| application.
| prospero wrote:
| My point is that the creator/user dichotomy exists at
| every level of software.
| zem wrote:
| if you think of the "end user" as the next person to work
| with the code, tellman's version is the ideal of
| encapsulation. some problem might be intrinsically hard to
| solve in terms of expressing it in code, but the end product
| could still be simple to work with given a properly
| encapsulated design
| readthenotes1 wrote:
| I read a research article long ago that said that most of the
| complexity measures investigated at the time were highly
| correlated with loc.
|
| For example, it's nice to measure McCabe cyclomatic complexity,
| and it generally rings true, but if you can't be bothered - just
| look at LOC and you'll get pretty close
| n0n0n4t0r wrote:
| For those who will stumble as me: Loc = lines of code. (He he,
| we were talking about complexity, weren't we?)
| 0xbadcafebee wrote:
| Yes, in the same way that large forces are highly correlated
| with bigger things. You don't have to know anything about
| design or engineering to know that an 18-wheeler will deal with
| larger forces than a sub-compact car. Similarly, a whole lotta
| software is gonna be more complex.
| _benton wrote:
| I like Ousterhout's the best because I think it's the most
| concrete out of the three. The other two are more subjective imo,
| of course still very useful and important.
|
| Although I think "dependency" is an overloaded term. There are
| dependencies as in libraries or shared code, and then there are
| "dependencies" which are like assumptions about other parts of
| the system. Hickey also mentions this when he talks about
| interfaces. If you break a class into two classes, but they both
| make assumptions about the other, in effect they are still the
| same class.
|
| Perhaps another way to think about complexity is the number of
| assumptions baked into a system?
| lioeters wrote:
| When I think about a system that makes _zero_ assumptions, I
| imagine it would have a large number of configuration points,
| where every single aspect of behavior and interaction must be
| specified explicitly instead of implicit and assumed. That
| sounds complex.
|
| On the flip side, a counter-example comes to mind: automatic
| imports ("autoloading") in some languages, which makes things
| apparently simple but gets gnarly when things break
| unexpectedly. It makes a lot of assumptions about your
| intention, which is simpler when it works the way you expect.
| I'd prefer explicit imports every time, even if it's verbose
| (some might call "complex") because it makes no assumptions -
| every import is visible so it's actually simpler to understand.
| layer8 wrote:
| It probably makes a difference whether it's a tower of
| assumptions building on one another, or a disparate set of
| unrelated assumptions. Assumptions also aren't equal: An
| assumption may be reasonable or unreasonable (likely to be
| violated), explicit or implicit.
| 0xbadcafebee wrote:
| When you see the words "complex", "simple", and "easy", keep this
| in mind: these are words that exist to help humans communicate
| their difficulty in interacting with the world.
|
| This whole post is a discussion of philosophy. There are three
| different ways you can think about software: -
| philosophy - science - function
|
| The philosophy of software involves people trying to understand
| what software is. Humans have a desire for knowledge and
| understanding, and like to explain things they come into contact
| with and think about. A lot of the time there's no "objective"
| philosophical explanation, try as we might to find one. Despite
| that, many explanations in this realm end up being useful.
|
| The science of software is computer science, which is more about
| math than anything else. This is the only place you're gonna find
| objectivity or consensus, because you can't really argue with a
| number. Discussions around CS are less poetic and more boring,
| and require a lot more knowledge, so you won't typically find
| these on HN.
|
| The function of software is the day-to-day practice of writing
| and using software. This is the grunt work, the meat and
| potatoes. No need for philosophy or science. Just put the legos
| together and kick the tires. This is 99% of what 99% of software
| developers deal with. Most people don't think about the science
| or philosophy of the coffee they're ordering or the bike they're
| riding; they're just ordering it, riding it.
| burakemir wrote:
| Enjoyed this, but looking at these from manager decision scenario
| is of course going to bias towards the more subjective.
|
| For a different scenario, imagine you operate a large distributed
| system and have been paged at 3 am because there is a problem.
| Besides taking steps to contain the fallout, you want to quickly
| locate the error and take steps to prevent this stuff from ever
| happening again.
|
| Unlike a hiring decision, you want to propose measures such that
| a large number of people get to agree that the state of affairs
| will improve. It is a truism that we don't want software to fail,
| so considering expectations may not necessarily help here, and
| rationality would suggest to strive to achieve an "objective"
| improvement - and one that does not make the system harder to
| understand or invite new, different failures.
|
| So all in all, I enjoyed this advocacy of Tellman's perspective,
| but it does not always seem appropriate to apply it and more meta
| than the others.
| redhale wrote:
| > I reached out to Tellman before writing this post for some
| clarifications.
|
| Ironic!
| adityaathalye wrote:
| I like to think of _software_ complexity in terms of the rocket
| equation [1].
|
| More generally, I imagine complexity as a dynamic multi-
| dimensional phenomenon, operating across time and space. The more
| complex a phenomenon is, the more it resists explanation. Static
| systems made of many many parts (fractals, amorphous materials
| etc...) can be simpler than dynamic systems made of very few
| parts (three body problem).
|
| _Behaviour_ makes all the difference [2].
|
| [1] https://www.evalapply.org/posts/software-
| debt/index.html#sof....
|
| Quoting oneself...
|
| > Complexity is to software what mass is to a rocket; the hard
| limiting factor of growth in any dimension you choose to measure
| (shipping velocity, headcount, revenue, cash flow, account
| expansion; anything). This is the sort of thing that demands
| tree-recursive, networked thinking we are not good at doing
| explicitly and deliberately. Something that our education
| actively disables by drilling us to think in simplistic linear
| terms in which correlation amounts to causation.
|
| [2] In this sense, I'd argue that the biggest baddest LLM
| contains far less _complexity_ than is contained in a living
| planarium.
|
| Though an LLM is a black box demonstrating emergent-looking
| behaviour, it is a pure function, once calculated. The _apparent_
| emergence is a function of us not knowing what bit-twiddles of
| the input space will lead to what bit responses out the other
| end. The probability distribution being fixed, LLM input-output
| relationships are countable (a finite game), though the number is
| too big for us to count.
|
| (P.S. I'm _certain_ of all of this because of my quadruple Phds
| in Biology, AI, Physics, and Maths. Totally not an Internet
| Rando. I swear.)
| amelius wrote:
| Surprised it didn't mention orthogonality.
___________________________________________________________________
(page generated 2025-06-15 23:01 UTC)