A claim worth treating carefully
Engineers often say that most problems live at the interfaces. The statement is a rule of thumb rather than a measured fact, and nobody can give a precise percentage. It is nevertheless a useful prompt, because it matches a common experience: parts that work on their own fail when joined, and the cause is usually a gap between what one side provides and what the other side expects.
An interface is any place where two parts, systems, people or teams exchange something. That includes a bolted joint, an electrical connector, a software function call, a data file format, a hand-off between shifts and a document passed from one team to another.
Why interfaces are fragile
Each side of an interface is usually designed by a different person or group, often at different times. Each makes reasonable decisions based on what they believe the other side does. Problems arise when those beliefs differ and nobody notices.
A few typical patterns:
- Different units or conventions. One side sends a length in millimetres and the other reads it as inches, or one counts from zero while the other counts from one. Famous failures have come from unit mismatches, which is why careful unit conversion matters so much.
- Different timing. A signal is valid only after a delay, but the receiver samples it immediately.
- Different ranges. The sender can produce values the receiver was never designed to accept.
- Missing cases. Nobody specified what happens when data is late, absent, duplicated or out of order.
- Different meanings. Two teams use the same word, such as “ready” or “complete”, for different states.
- Unowned responsibilities. Each side assumes the other handles a task, such as error checking, so nobody does.
In each case, both sides may be internally correct. The failure sits in the space between them, which is why component-level checks do not find it.
Types of interface
It helps to name the kind of interface, since each calls for different details.
- Mechanical: dimensions, tolerances, fasteners, loads, materials, assembly order.
- Electrical: voltage and current levels, connector pinouts, grounding, signal timing, noise.
- Software and data: function signatures, message formats, error handling, versioning.
- Fluid or thermal: flow rates, pressures, temperatures, heat paths.
- Human and organisational: who hands what to whom, in what form, by when, and who confirms receipt.
Real connections often combine several kinds at once. A connector, for example, is mechanical, electrical and sometimes thermal.
What a clear interface definition contains
A good definition makes assumptions explicit so that both sides can check them. A reasonable minimum includes:
- Purpose: what the interface is for, in a sentence.
- Items exchanged: each signal, material, energy flow, message or document, with its direction.
- Limits: valid ranges, resolution and tolerances. For electrical parts, this is where information like absolute maximum ratings and recommended operating conditions comes in.
- Timing and sequence: what happens first, how long things take, and what happens on start-up and shutdown.
- Behaviour in abnormal cases: missing, late or invalid inputs; overload; disconnection.
- Ownership: who is responsible for each side, and who approves changes.
- Version and date: so that both sides know which definition they are working to.
Written in a shared place and in plain wording, this document becomes the reference when the two sides disagree. It should specify what is required, not how each side achieves it, so that both remain free to change their internals.
An illustration
Suppose one team builds a sensor module and another builds the controller that reads it. A weak interface statement might say, “The sensor sends temperature to the controller.” A clearer one would say what units are used, the valid range, how often a reading is sent, what a “no reading available” value looks like, and what the controller should do if no message arrives for a given period.
Nothing here is exotic. The improvement is simply that each question has a written answer, so a mismatch shows up in a review rather than during integration. This kind of precision overlaps with the work of writing requirements and technical specifications, and the same habits apply: avoid vague words and make statements checkable.
Habits that help
- Draw the interfaces. Every arrow crossing a box edge on a block diagram is a candidate for a definition. Start with the ones that cross team boundaries.
- Name an owner. An interface without an owner tends to drift. Agree who maintains it and how changes are proposed.
- Review from both sides. Ask each team to explain the interface in its own words. Differences in explanation reveal differences in assumption.
- Integrate early and often. Test the connection between parts as soon as rough versions exist, using placeholders or simulators if necessary. Integration testing exists largely for this reason.
- Control changes. A change on one side can quietly break the other. Treat interface changes as requiring notice and agreement, and record the reasoning, for example in decision records.
- Test the edges. Try the boundaries of ranges, missing inputs and start-up sequences, not just the typical case.
- Talk. Written definitions help, but they do not replace conversation. Good team communication across the boundary often surfaces issues that a document would not.
Limits of this advice
Written interfaces cannot capture everything. Over-specifying can slow work and create documents nobody reads, so the level of detail should match the risk of getting it wrong. Interfaces that involve safety, regulated products or critical infrastructure usually call for formal processes defined by the applicable standards, which vary by country and industry. This article is general background rather than professional engineering advice.
The practical message is modest: when something fails after two good parts are joined, look first at what each side assumed about the other, and write those assumptions down before they cause trouble.