Terminological ambiguity in Chapter 2 of A Philosophy of Software Design

[Pierre Arnaud]

Dear John,

I’m currently reading A Philosophy of Software Design, and I appreciate the clarity with which you expose many key issues in software development — especially the long-term costs of complexity and the need to reduce cognitive load through deep modules and clean abstractions.

That being said, I was surprised — and to be honest, a bit disappointed — by the lack of distinction between complexity and complication in Chapter 2.

In my view (and I believe in many others’), these two concepts are fundamentally different:

• Complexity is intrinsic, often essential to the domain or problem being solved.

• Complication is accidental, a result of poor design decisions, unnecessary abstractions, or lack of clarity.

Blurring this distinction may weaken the argument, especially in a chapter that aims to define what makes code hard to understand. I do appreciate your addition of obscurity as a contributing factor to perceived complexity, that’s a valuable insight.

I’m curious: was this a deliberate choice to simplify the discussion early on, or do you consider the terms interchangeable in the context of the book?

Thank you for your work and your contributions to the software design community. I’d be glad to hear your thoughts. And I’m looking forward to reading the next chapters.

Best regards

Dr. Pierre Arnaud, CEO

Epsitec SA

[Jonathan Camenisch]

Hello Dr. Arnaud,

As a bystander to this conversation, I would like to point out that the terms "complexity" and "complication" have been used in a variety of ways, and have the typical ambiguity of English words. Your use of the terms "essential" and "accidental" sound like an echo of Fred Brooks' classic paper, "No Silver Bullet: Essence and Accidents of Software Engineering." In that paper he makes much of the distinction between "essential difficulties" and "accidental difficulties." He even uses the phrase "accidental complexity" in the course of making this distinction—which associates complexity with the accidental kind as well as the essential.

In more recent years, Rich Hickey's famous talk entitled "Simple Made Easy" is a thought-provoking reflection that uses the term "complexity." He riffs on the etymology of the Latin root of complexity, which means "interwoven" or "braided." From there he warns against the evils of "complecting" things instead of keeping them simple in a rigorous sense. You may or may not agree with Rich Hickey's approach, but I think the talk is a significant data point on how terms are used in the industry by important thinkers—with or without broad consensus on exact definitions.

As long as you define your terms, I am willing to interpret your words in the sense that you mean them—in order to obtain the real gem which is the ideas you seek to transmit from your mind to mine.

Best regards,

Jonathan

--
You received this message because you are subscribed to the Google Groups "software-design-book" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software-design-...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/software-design-book/C396F190-8F71-43BF-A232-60F785082704%40opac.ch.