Replace the part without redesigning its neighbors

Cross-Domain EchoesShared pattern · Modularity

A replaceable avionics unit can be removed from a standard tray and exchanged for another that meets the same connection and function specification. Modular software aims for a related freedom: a bounded component can change internally while its promised services stay compatible with the rest of the program. The visible seam is doing much of the work. Merely putting something in a separate box or file does not make it independently replaceable. The examples share a design question—what must the replacement preserve for its neighbors?—while differing in their constraints: physical access, fit and signals on one side, behavior and dependencies on the other.

Written comparison

The replaceable responsibility

Avionics maintenance

Complete equipment function

Software engineering

Bounded software responsibility

The unit must own enough of the function that a change does not leave a dangling dependency elsewhere.

What the seam promises

Avionics maintenance

Fit, signals and function specification

Software engineering

Service interface and behavior

Replacement is conditional on the contract, not just on a similar name or container.

What stays stable outside

Avionics maintenance

Connections to surrounding avionics

Software engineering

Other modules’ expectations

The goal is to localize revision while neighbors can continue relying on the agreed surface.

What carries across

To make something replaceable, specify what its neighbors can rely on and keep internal changes behind that seam.

Where the comparison stops

A physical replacement needs access, isolation and compatible hardware. Software replacement has different behavioral, state and deployment constraints.

• Neither source establishes that arbitrary replacement is safe merely because a connector fits or an interface signature matches.
• Modularity limits propagation; it does not eliminate every cross-module dependency or make system verification unnecessary.
• Physical removal and software deployment are not the same operation and do not share a universal cost or time saving.

Conditions for this comparison

• The physical unit is accessible and removable without disturbing adjacent units, and honors the full interface specification.
• Software boundaries are cohesive and intermodule dependencies are explicit and controlled.

Source entries

Shared pattern

Modularity

Prime

Core Idea

the ability to replace or upgrade individual modules without redesigning the entire system.

Avionics maintenance

Replaceable Unit and Standardized Connector

Mechanism

Example

An aircraft's radio altimeter is built as a line-replaceable unit (LRU) — a sealed box in a standard tray with a blind-mate connector at the back. When one fails, a line technician pulls the box and seats a spare in a few minutes on the flight line; no soldering, no recalibrating the surrounding avionics, no aircraft-specific fit-up. The failed unit goes to a depot for deep repair on its own schedule, entirely decoupled from the aircraft's.

How it works

- Bound the unit around a whole function. The unit is the smallest piece that carries a complete, testable responsibility — so swapping it swaps the function cleanly, with no dangling remainder. - Define a standardized connector. Mechanical fit, power/signal pinout, and logical protocol are fixed by a published spec, so conformance — not custom fit-up — is what makes a replacement work. - Guarantee reach and separation. The unit can be accessed, isolated, and non-destructively removed via that connector without disturbing neighbors. - Interchange, don't rebuild. Repair, upgrade, and second-sourcing happen at the unit level on their own schedule.

Software engineering

Modular programming

Domain-specific abstraction

Core Idea

Modular programming organizes a system so each module owns a bounded responsibility and exposes selected services while hiding implementation detail. Interface contracts permit independent reasoning, replacement, testing, and reuse while dependency direction limits the propagation of changes. The abstraction is therefore identified by a declared carrier, a transformation or constraint over that carrier, and an invariant that tells an analyst whether the named structure is genuinely present.

What It Is Not

- It is not the neighboring catalog concept Structured programming. Structured programming organizes control flow within programs; modular programming organizes system responsibilities and interfaces across units.