One of the biggest problems in software development is the erroneous assumption that there comes a…

But because digital rot never sleeps, software cannot be viewed as being something similar to a physical object, such as a chair, or a…

One of the biggest problems in software development is the erroneous assumption that there comes a point where software is done. In reality, software is constantly evolving. There is always work that needs to be done on software, unlike for example if we deliver a chair. Once built and delivered, a chair is completely done; no need to ever do any more work on it.

But because digital rot never sleeps, software cannot be viewed as being something similar to a physical object, such as a chair, or a wristwatch, etc.

What that means is that various software systems interact with each other (there is certain dependency), while each of those systems evolves at their own pace. Breakages happen when the pace of evolving is mismatched -- one system changes how it works, and other systems that depend on it break because of that change and thus the entire system stops working.

It is for that reason that a good design implements large volumes of ambiguity, as well as apathy for details.

In your example, if we were to look at the simple system as if it is a chair, something that, once built, will not keep changing, the tight coupling would be okay. But in reality, it is highly unlikely that such simple system will remain put. It will keep evolving, and one part of the system may evolve at different rate than the other parts, breaking the coupling in the process.

Which is why it is not advisable to design software where dependencies are tightly coupled.