When is tight coupling essential or a good thing?

Question

From all my readings and research on OO design/patterns/principles I've found that the general consensus is that loose coupling (and high cohesion) is the almost always the better design. I completely agree speaking from my past software project experiences.

But let's say some particular software company (which I don't work at) has some questionably designed large scale software that interacts with some hardware. The modules (that I never worked on) are so tightly coupled and function calls that goes 20+ levels deep to manage states. Class boundaries are never clearly defined and use cases poorly thought up. A good software developer (not me) would bring up these issues but only get turned down by the more senior developers that development practices (like SOLID or TDD) doesn't really apply because the software has worked for years using the "traditional" methodology, and it's too late to change. And the biggest complains from the customers (which I don't know who they are) are of the quality of the product.

Because of the above unrealistic scenario (I was never apart of), I thought about if there are cases where tight coupling is preferred or even required? When are there cases where developer needs to cross module boundaries and share states and increase dependency and reduce testability? What are some examples of systems that's so complex that would require this? I couldn't come up with a good case myself so I'm hoping some of the more experienced craftsmen can help me out.

Thanks. Again, I don't know this company.

Sheffie

When developers lack knowledge or experience, and managers lack patience or budget, tight coupling is inevitable. – Spindell

Probably if you're prototyping something, and want to do it fast and the code will be thrown out the door afterwards anyway. – Prothrombin

I agree with prototypes and experimental code, or something like a competition or hackathon where development speed is priority. But if it is any type of serious project where paying customers are involved, are there engineering instances of tightly coupled design that is beneficial? Of course under the assumption that the customer wants quality first and deadline second. – Sheffie

Answer 1

A tightly coupled architecture integrates enterprise applications around a single point of truth, which is often a single spatially-enabled RDBMS. The types of applications that are linked include engineering design (CAD), facility records management (GIS), asset management, workflow, ERP, CRM, outage management, and other enterprise applications.

A major advantage of a tightly coupled architecture is that it enables the rapid and efficient processing of large volumes of data, provides a single point of truth instead of several, often redundant, data sources, and enables open access to data throughout the organization.

Tightly coupled architectures rely on standards such as SQL, ODBC, JDBC, and OLEDB, SQL/MM, and the Simple Feature Specification for SQL from the OGC, to provide open and secure access to data, including geo-spatial data, throughout the organization.

Loosely coupled Web services require substantial redundancies unlike tight coupling between clients and service, which minimizes redundancies.

One problem with asynchronous loosely coupled Web services is that for some business functions, it can exceed its resource capacity for the message queuing servers or system.

Loosely coupled Web services can be made to switch to tight coupling mode to avoid system overloads of scarce resources.

Lunetta

Please let me know if I understand your point correctly: if an application is dependent upon a third party module (in your case often some sort of RDBMS) is required to have tightly coupled because the third party module demands so for performance resource requirements. I don't see this as being advantageous to have tight coupling rather than being forced to have coupled design due to third party limitations. I remember watching presentations about NoSQL movement that addresses this issues. BTW the fictional company does not use any databases at all – Sheffie

Its not about third parties. Yes perfomance issue is there, but what I meant to say is that, if processes are managed centrally, this results in tight coupling between the different sub-processes and transactions. For example, database mechanisms (RDBMS) might be used for ensuring referential integrity and general consistency of the data owned by the different sub-processes. This is often the case, for example, with large, monolithic ERP (Enterprise Resource Planning) systems. – Lunetta