"Loose coupling" is one of the basic principles they tell you in beginner's courses. This is common knowledge to the point of being cliche. This encourages comi

"Loose coupling" is one of the basic principles they tell you in beginner's courses. This is common knowledge to the point of being cliche. This encourages coming up with good boundaries, interfaces, whose both sides can independently vary. Choosing these separation points is not trivial, by the way. It usually requires many iterations and a good gut feeling for what future requirements may arise. One example that is frequently mentioned is content vs form, for example website content and its presentation. It's useful, but still strongly depends on the actual uses. What works on screens doesn't necessarily work on paper. Not all forms can accommodate any kind of content. In other words the content also needs to fit the form. Or see how the layered model of the TPC/IP or the ISO-OSI protocols actually isn't that principled in practice. A high-level protocol may want to adjust its workings depending on what lower-level protocol it is running over. So decoupling is not trivial. It often reduces performance too. Say you want to chain two tools sequentially. What if you end up using a specific combination 90% of the time, but there is some intermediate step in the first component that calculates something that is thrown away and the second component needs to recompute it because the general interface between the two doesn't include passing that data along? Then you can either accept it, or tightly couple them, OR even worse: you may try to find the real pure elegant reason for why this piece of data is actually logically required there and then you end up with abstractions that only have one instantiation, just for the sake of not "hard-coding" things. But anyway, back to the core issue. There is not much to be surprised about. Complexity of system = Complexity of individual components + Complexity of their interactions This is analogous to the decomposition of the variance of a set of numbers: total variance = variance inside groups + variance between different groups. There is also some physical analogy for calculating energies, where you need to take couplings into account. If you have a big system you need to take care of lots of interactions. If you choose to use small independent tools, then you need to write the code for their interaction. Should the components come from the same vendor or different ones? There are arguments for both. Use same: they tested all sorts of interactions and fixed any bugs that they found (Apple supporters often point to this). Use different: each component only cares about its job, so less bugs in them, clear responsibilities etc. Certainly, if the same vendor develops all components of the system, they don't have to be so conceptually clean and they may make up for bugs in one subsystem by quirky code that tries to cancel out the bug's effects in some other subsystem, leading to fragile software.