But, for example, say we are talking about a communication module. One module may use a well-known library as a bundled dependency, and another module may use the same one. They may be smart enough to use dylibs, in which case, you have the potential for "DLL hell," or they may use static libs, in which case you have duplication of code, and maybe resource contention.
I would not consider static libraries to be duplication of code. Duplication of assemblies or compilation unit, sure, but not code. The code itself has not been duplicated.
Yeah, like my node_modules folder doesn't contain tons of duplicate code.
/s
Regarding the development experience:
I think it's a tug and back-and-forth kind of dynamic.
Modularity has exactly the kind of effect you talk about, until it doesn't.
At some point, the cost of communication (between people!) responsible for different modules can increase until it's a net negative to try to adapt a module, or even find out it exists and is suitable.
Of course, a monolithic project of comparable size has likely collapsed from its weight into a ball of mud.
Development tools have come quite a ways, but the science of getting teams to develop software together, perhaps not so much.
Yup. I think I'll put that on a T-shirt.
I just can't conceive of how modularity, in general, causes duplicate code rather than reduces it. And this is before considering something like generic code which could potentially further reduce duplication. Every time we've been deliberate about using modularity in projects it ends up creating libraries that reduce the total amount of code across projects. Even if it's just in one project, good modularity has been used to reduce a lot of duplication.