Overview
Defence technology software is ordinary engineering under four constraints the rest of this site assumes away: there is no reliable network, the attacker is funded and patient, a wrong output costs far more than a bad quarter, and the user is not at a desk with time to learn. Almost everything else on this site assumes the opposite of all four. Remove them and the engineering does not become exotic — it becomes strict. This page names the four constraints, shows what each one replaces, and covers the parts of the working environment that surprise people arriving from product engineering.
- Constraints
- Four, and they compound
- Design centre
- The failure case
- Definition of done
- Includes being wrong
The four constraints, and what each one replaces
There is no single "defence technology" style of engineering, and looking for one is the fastest way to build something that impresses in a demonstration and fails in use. What exists instead is a set of assumptions that ordinary practice makes silently and this domain cannot. Four of them matter enough to be named, and each has a specific consequence rather than a general mood of seriousness.
The first is the one that changes the most code. "The network is unreliable" is a sentence every backend engineer agrees with and very few systems are actually built for, because in practice it means slow or occasionally lossy — a retry fixes it. Here it means absent, for hours, without warning, and both sides keep working while it is gone. A system built for latency retries and eventually succeeds; a system built for partition does its job alone, records what it did, and reconciles when contact returns. Those are different architectures, not different timeout values.
What actually changes in the daily practice
The constraints are abstract until you put them next to the practices they overturn. The table below is deliberately written against the rest of this site — each left-hand cell is something argued for elsewhere in these pages and correct there.
| Ordinary practice | What replaces it here | Because |
|---|---|---|
| Deploy several times a day; fix forward | Releases are infrequent, signed, staged and reversible on the device itself | The unit may be unreachable for weeks, so the version it is running has to be safe on its own for weeks. |
| Observe production and iterate on real usage | Recorded logs collected later, plus simulation as the main feedback loop | There is no live telemetry stream to read, and often no way to ask the operator what happened. |
| Add a dependency when it saves a week | Every dependency is a supply-chain decision with an owner and a provenance record | The adversary reads your dependency list too, and a compromised build reaches every unit at once. |
| Target high availability as a percentage | Target graceful degradation: name what still works at each level of loss | Nines describe a service that is either up or down. Here the interesting states are the partial ones. |
| Definition of done: it works and the tests pass | Definition of done includes what it does when it is wrong, jammed, captured or unattended | The failure case is not an edge case here; it is the expected operating condition. |
The working environment, which nobody warns you about
The technical constraints are the half that is discussed. The other half is how work arrives, how it is judged and how long it lives, and it differs from product engineering enough to be worth stating plainly.
Requirements arrive as documents
Not as a backlog you shape with discovery. Much of the skill is reading a specification written by someone who will never meet you, and finding the sentence that decides the architecture.
Interoperability is mandatory
Your system will be asked to exchange data with systems chosen by someone else, often older than it and not changeable. Message standards are a requirement, not a design preference.
Lifecycles are long
Ten to twenty years is normal. That changes every dependency decision, every data format decision, and makes "we will rewrite it later" a claim somebody will hold you to.
Evidence is part of the work
Showing that something works is a deliverable with its own effort estimate — test records, traceability from requirement to test, an argument for why the safety case holds.
Two more constraints are legal rather than technical and are worth knowing before you take the work rather than after. Much of this software is export-controlled, which restricts who may hold the source, where it may be built and who may be told what it does — a rule that reaches into ordinary decisions like which cloud region a repository lives in. And a great deal of it is dual-use: the same detection pipeline serves search and rescue, wildlife survey and border monitoring. That is a real property of the field and it is also not a licence to skip the question of what a system is for. The honest position is that the question belongs in the design review, with a written answer, alongside the threat model.
Human in the loop as an engineering requirement
The phrase is used loosely enough to mean nothing. As an engineering requirement it is specific, and it decomposes into properties you can test for. A system has a human in the loop when a person must act before a consequential action happens; it has a human on the loop when the system acts and a person can stop it; and it has neither when the person is shown a result they have no realistic ability to evaluate or interrupt. The third case is the common one, and it usually arrives by accident rather than by decision.
- The person must have enough time to decide. A confirmation dialog with a two-second timeout is not oversight; it is a rubber stamp with extra latency.
- The person must be able to see why. A confidence number without the evidence behind it — which sensor, how old, what it matched — cannot be evaluated by anyone.
- Refusing must be as easy as accepting, and must not look like a mistake. If the interface makes "no" harder than "yes", the loop is decorative.
- The decision must be recorded — what was shown, what was chosen, when, by whom. Without that record there is no way to review a bad outcome and no way to improve the system.
- Automation bias is a design problem, not a training problem. A system that is right most of the time trains people to stop checking, so the interface has to keep making the uncertain cases feel uncertain.
Anti-patterns worth naming
- Building for the demonstration: good weather, full battery, a strong link and the author standing next to it.
- Treating the threat model as a review step at the end, where it can only produce a list of things you will not have time to change.
- Assuming the operator will read a manual. They will not, and the interface is what they will have instead.
- Copying a cloud architecture wholesale into an environment with no cloud, which produces a system that is unavailable exactly when it is needed.
- Leaving the question of what the system is for to somebody else, on the grounds that it is dual-use.
When to use it
Use it when
- As the first page of this section — the other five assume these four constraints without restating them.
- When deciding whether an ordinary architecture transfers to a disconnected, contested or unattended setting.
- As a checklist for a design review: what happens when it is wrong, jammed, captured or alone.
- To set expectations for a team moving here from product engineering, before the first sprint rather than after it.
Avoid it when
- As a source of specifics — the mechanisms live on the five topic pages, and this one deliberately does not repeat them.
- As an argument that this domain needs different fundamentals. It needs the same ones held to more strictly.
- As a substitute for a written threat model, which is specific to a system and cannot be inherited from a page.
- To justify skipping ordinary engineering discipline. Every practice in the other four sections still applies here.
Found this useful?
Share it with someone who is working on the same problem.