Tight Coupling Makes Change Difficult

27 July 2023 by Phillip Johnston

One of the most pernicious problems in software engineering is tight coupling, and it contributes significantly to making software difficult to change.

Coupling is a qualitative measure of how much one component or module depends on other components or modules in the system. When changing one component requires corresponding changes in another software component, those two components are tightly coupled. When changes in one component rarely (or never) requires changes in another component, those two components are loosely coupled.

Tight coupling has many observable consequences for your software:

• Individual modules and components are more difficult to reuse. To reuse a tightly coupled piece of code, all of its dependencies must be satisfied in the next system. This can introduce a sufficiently high barrier for reuse, making it more expedient to re-implement the functionality than reuse the proven solution.
• Individual modules and components are more difficult to test in isolation – you must bring in all the dependencies in order to test the module, and testing without hardware becomes difficult or impossible. When testing is difficult, you’ll likely skip it. Without automated tests, you cannot change and refactor your system with confidence.
• It makes the program more difficult to reason about, since changes in one module can affect multiple modules within a system in unexpected ways.
• Whenever there is a change in a tightly coupled dependency, you must propagate that change to all other coupled modules.
• Changing requirements, design decisions, and hardware components will typically trigger large or wide-ranging changes in the system.

Over time, these consequences add up and result in reduced system maintainability and flexibility of the system, quickly leading to software aging.

Of course, tight coupling has been the status quo in embedded software and it occasionally works out. But it is always a gamble. You’re betting on the idea that you won’t need to make fundamental changes to your system – and in our experience, that rarely holds true, especially as the complexity of the systems we build increases. In order for a tightly coupled system to avoid schedule delays, you must make a significant up-front time investment to ensure that the choices made at the beginning of the development lifecycle will be suitable for the product’s entire lifetime. Any changes in the system, even long-term, become much more expensive and difficult to make when dealing with tight coupling. Unfortunately, in today’s agile world, up-front design has been wholly de-emphasized. Tight coupling arises out of expediency, not deliberate planning and decision making.

Minimizing coupling allows components and modules to be used, changed, swapped, and tested independently from other components or modules in the system. These software properties enable true agility.

There are four common coupling sources that present challenges specific to embedded software development:

1. Processor dependencies
2. RTOS dependencies
3. Hardware dependencies
4. Library and framework dependencies

Even developers who pay attention to coupling in their own modules commonly ignore these coupling sources. However, as we’ll show in the following lessons, if you don’t aggressively resist these sources of coupling, they will eventually wreak havoc on your embedded software.

References

• Coupling
• Dependencies Make Reuse Difficult
• Musings on the Tight Coupling Between Firmware and Hardware
• Prototyping and Design for Change: Lightweight Architectural Strategies
• Timeless Laws of Software Development by Jerry Fitzpatrick
• Maintainability
• The complexity of our systems is increasing, but we are creating products with smaller teams