the ideal world

[Paul Becker]

Hello all,

There is a part in APOSD which has been bothering me for some time now:

"In an ideal world, each module would be completely independent of the
others: a developer could work in any of the modules without knowing
anything about any of the other modules. In this world, the complexity
of a system would be the complexity of its worst module. /
Unfortunately, this ideal is not achievable. Modules must work together
by calling each other's functions or methods. As a result, modules must
know something about each other. [...] The goal of modular design is to
minimize the dependencies between modules." (4.1)

I don't think that this is a good description of the ideal world; it
takes it too far. Modules that don't interact at all cannot function
together. The goal is a functioning program, and thus any ideal must
still be a functioning program. But the clue to the actual ideal is
right there in the text: "modules must work together," and "the goal
[...] is to minimize the dependencies." I propose something like this
instead:

In an ideal world, each module would be completely independent of most
others: a developer could work in any of the modules without knowing
anything about most of the other modules. In this world, the complexity
of a system would be close to the complexity of its worst module. / This
ideal can be hard to achieve. Modules must work together by calling each
other's functions or methods. It can be difficult to design modules so
that they don't need to know something about each other. [...] The goal
of modular design is to minimize the dependencies between modules.

Thoughts?

paul

[Mahmoud Fayed]

Hello Paul

>> "I don't think that this is a good description of the ideal world; it takes it too far. Modules that don't interact at all cannot function together."

IMHO, the book description is correct and amazing, 

>> "Modules that don't interact at all cannot function together"

They can, if they are used by a program/system that can call them

For example, think of unix programs where each program could get an input and produce an output

And we can pass the output of a program to another program as input

Also, think of us (humans) we could discover new people, interact with them and learn about them

Programs could apply this pattern and (discover other programs based on need) and interact with them (through a protocol) 

i.e. we can design programs/modules that don't know about other modules (during the design time) but could (interact) with them through input/output or through (discover & use) or (through an external program who manage the process).

>> " In this world, the complexity of a system would be close to the complexity of its worst module. / This ideal can be hard to achieve. Modules must work together by calling each

other's functions or methods"

When we build a programming language we could build a package manager, such packages could be used together even if they are designed by different people for different purpose. 

The point is finding a way of communication but defer it to be at usage time (not design time) 

Simple example: I could use a library for GUI, another library of database, they don't know about each other, but I can write the glue so I can control my GUI to display the data in my database.

Greetings,

Mahmoud

[John Ousterhout]

On Mon, May 11, 2026 at 3:16 PM Paul Becker <rainc...@gmail.com> wrote:

Hello all,

There is a part in APOSD which has been bothering me for some time now:

"In an ideal world, each module would be completely independent of the
others: a developer could work in any of the modules without knowing
anything about any of the other modules. In this world, the complexity
of a system would be the complexity of its worst module. /
Unfortunately, this ideal is not achievable. Modules must work together
by calling each other's functions or methods. As a result, modules must
know something about each other. [...] The goal of modular design is to
minimize the dependencies between modules." (4.1)

I don't think that this is a good description of the ideal world; it
takes it too far. Modules that don't interact at all cannot function
together. The goal is a functioning program, and thus any ideal must
still be a functioning program. 

Technically you are right, of course. I exaggerated in order to make a point. When someone says "ideally" they are almost always talking about something that isn't actually practical. In a truly ideal world I would be able to use other modules without having to know anything about them. I have no idea how that could be achieved, but it would be nice, no? :-)

-John-

[Mahmoud Fayed]

Hello John

>> "In a truly ideal world I would be able to use other modules without having to know anything about them. I have no idea how that could be achieved, but it would be nice, no? :"

Maybe through the next steps

(1) Design/implement each module in isolation from other modules (No knowledge about other modules)

(2) For each module provide an API that can be used with other module (i.e. public - but not known to other modules)

(3) For communication a mix of the next ideas/features could be used

* Reflection ---> To discover public API provided by modules

* Automatic Code Generation (Maybe using Eval() too if we are using a dynamic language)

* Prompts to LLMs (where we could share the modules documentation/API/reflection results with the LLM)

The point is to have a communication between two modules, this could be (direct) or (indirect)

And it it's (indirect) this could be (manual) or (automatic)

I guess if it's (indirect) and (automatic) ---> Then we achieved the goal of designing modules that can work together without knowing each other.

But in reality, a system will know, like the reflection system or LLM, etc.

Greetings,

Mahmoud

[Jim Lyon]

I'm with John when he describes his ideal, but I also realize that the ideal is not obtainable. In most large projects, there are overarching decisions that affect everything: what's your threading model, your persistence model, your logging / error reporting model, etc. In older C/C++ code bases that pre-date high-quality STL implementations, this even includes things like which string and container classes you will use. Will you throw exceptions, or will you return error codes? How is your system broken up into processes, and how to they communicate? And so forth.

For any individual module, many of these decisions will not affect the interface, but only the implementation. But in a huge number of cases, these "architectural" [scare quotes intended] decisions affect many interface decisions. Ideally, they wouldn't, but in practice they do.

-- jimbo

[Paul Becker]

I think that the distinction i'm trying to make is between these two positions:

1. Dependencies are bad. Our work is to eliminate them.

2. Dependencies are essential. Our work is to identify, organize, simplify, and clarify them.

It's not about ideal versus practical---it's about our basic values and where they take us in the extreme.

I don't think that having to know things about other modules is a problem. Learning about and using a good module is one of my favorite experiences in programming. I think that the problem is when that knowledge is difficult to acquire or use---namely, complexity.

Even just the idea of using a module at all---"creating a dependency"---is the essence of modularity. It's a way to manage complexity. Perhaps i am saying that dependencies in themselves aren't a source of complexity, but obscure dependencies are.

Many thanks for the discussion,

paul

--
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/434e3bf2-8df5-4a52-b70b-741f139a13f0n%40googlegroups.com.

[Jim Lyon]

It's not that dependencies are intrinsically bad. In fact, they are essential. The problem is that when you draw a graph of the dependencies between modules, your ability to understand and change the system is inversely proportional to [the square of] the density of the graph. Therefore, the job is to minimize unnecessary dependencies.

-- jimbo

PS: Regarding the bracketed phrase [the square of] ...  I believe that your inability to change something increases more than linearly with the density of dependencies, but I don't have empirical evidence to support that statement. Caveat lector.

[John Ousterhout]

On Sat, May 16, 2026 at 5:41 AM Paul Becker <rainc...@gmail.com> wrote:

I think that the distinction i'm trying to make is between these two positions:

1. Dependencies are bad. Our work is to eliminate them.

2. Dependencies are essential. Our work is to identify, organize, simplify, and clarify them.

It's not about ideal versus practical---it's about our basic values and where they take us in the extreme.

I don't think that having to know things about other modules is a problem. Learning about and using a good module is one of my favorite experiences in programming. I think that the problem is when that knowledge is difficult to acquire or use---namely, complexity.

Even just the idea of using a module at all---"creating a dependency"---is the essence of modularity. It's a way to manage complexity. Perhaps i am saying that dependencies in themselves aren't a source of complexity, but obscure dependencies are.

I disagree with this. I don't think there's any such thing as a "good" dependency; we may not be able to get rid of all them but they are all undesirable. Imagine two systems that are identical in every respect except one has an additional dependency not present in the other; can you identify a scenario where the system with the extra dependency is better?

In my view, defining a good module doesn't add dependencies; it eliminates them. Without a clean module, the rest of the system has a large number of dependencies on myriad details of the implementation of the functionality. By defining a clean module we eliminate most of those dependencies, replacing them with a smaller and simpler set.

-John-