Good argument on managing complexity



  • Also name-drops HyperCard.



  • No codinghorror links? I am surprised.



  • Wow, what a bunch of useless ivory tower claptrap. The guy should try leading by example instead of writing highscool debate club-level tracts.



  • Seems sensible, though the reason the "mathematically inclined" value expressiveness is that there are a couple of very common design patterns that can, and should, be expressed using as little notation as possible. The ideas are natural, and the notation should not get in the way.


  • kills Dumbledore

    One surrogate measure [of complexity] is the size of the documentation

    Not keen on that. Lots of hideously complex programs have next to no documentation. The size of documentation required to understand it, maybe


  • ♿ (Parody)

    It's a great goal. The problem is that it's harder to make something simple than something complex. It's the old, "I wrote a long letter because I didn't have time to write a shorter one."

    While I generally have simplicity as a goal in what I do, it almost always conflicts with what really needs to happen. "We need to do X. But when Y happens, don't do X, do W. And..."

    And then what began as simple may or may not scale, but scale is its own form of complexity. So, yeah, mostly ivory tower bullshit.


  • Discourse touched me in a no-no place

    That “manifesto” was all wrong. Too long for bullet points, too short for anything with thought or argument involved (unless 240 characters counts as “long argument” for the Twitter generation).



  • @jaloopa said:

    Not keen on that. Lots of hideously complex programs have next to no documentation. The size of documentation required to understand it, maybe

    I agree that it is the size of the documentation corpus required to understand what's going on, not the size of the documentation corpus that exists, that matters here.



  • @boomzilla said:

    The problem is that it's harder to make something simple than something complex. It's the old, "I wrote a long letter because I didn't have time to write a shorter one."

    While I generally have simplicity as a goal in what I do, it almost always conflicts with what really needs to happen. "We need to do X. But when Y happens, don't do X, do W. And..."

    It is indeed a case of "we kept tacking bits on a letter because we didn't have time to think of how to rewrite the existing ones to say what we need them to" in most software systems.

    As you (indirectly) point out, this is common in business processes too, especially with the push towards standardized, documented processes for well, almost everything. Legal and regulatory codes also suffer from this kind of creep, unfortunately.

    Another factor is that many business systems and processes are ad-hoc, with no unifying conceptual basis, or one that is not captured by the business. Objects not only get multiplied unnecessarily, they capture individual facets of the subject matter without getting to the concepts underlying it, if they even exist in the first place.


Log in to reply