Maintainability: Operability, Simplicity, Evolvability
Why this matters: maintainability is the NFR nobody puts on the whiteboard and everybody pays for. It never causes an outage directly — it decides how long every outage lasts, and how much of your team's time gets spent not building things.
Key takeaway
Maintainability is a system's ability to be easily operated, understood, and modified. It is measured primarily through MTTR, and because availability is MTBF / (MTBF + MTTR), maintainability sets a hard ceiling on the availability you can ever reach.
What maintainability is
After building a system, engineers must keep it operational. That means fixing bugs, adding features, updating dependencies, responding to incidents, migrating data, and adapting to requirements nobody anticipated. The majority of a system's total cost is incurred here, not during the initial build.
Maintainability decomposes into three distinct properties:
| Property | The question | What good looks like |
|---|---|---|
| Operability | Can we run it smoothly? | Good observability, sane defaults, automated routine tasks, clear runbooks |
| Simplicity | Can a new engineer understand it? | Clear abstractions, minimal accidental complexity, predictable behavior |
| Evolvability | Can we change it safely? | Loose coupling, tests that catch regressions, safe migrations, reversible deploys |
Measuring maintainability
The primary metric is MTTR — mean time to repair:
MTTR = Total Maintenance Time / Total Number of Repairs
MTTR is a proxy for maintainability because repair time is dominated by things that are properties of the system's design, not of the failure:
| Phase of an incident | What determines its duration | Maintainability lever |
|---|---|---|
| Detect | Whether monitoring catches it or a customer reports it | Observability, alerting on user-visible symptoms |
| Diagnose | How long to find which component and why | Tracing, structured logs, simplicity of the design |
| Mitigate | Whether a rollback or failover exists | Automation, reversible deploys, feature flags |
| Verify | Whether you can confirm the fix worked | Meaningful dashboards and SLIs |
Notice that only one of those four phases involves fixing anything. Detection and diagnosis routinely consume most of an incident, and both are pure design properties decided months earlier.
Maintainability and reliability
The two reinforce each other, in both directions.
Maintainability improves reliability. A system that is easy to understand gets fewer bugs introduced into it. A system that is easy to change gets patched promptly instead of accumulating known-bad code. A system that is easy to operate gets its warnings noticed before they become failures.
Poor maintainability degrades reliability over time. As complexity grows, changes become riskier, engineers avoid touching fragile areas, dependencies go un-upgraded, and failure rates climb. This is the mechanism by which systems rot — not one catastrophic decision, but the steady accumulation of changes nobody dares to make.
And both flow into availability:
Availability = MTBF / (MTBF + MTTR) Maintainability lowers MTTR -> raises availability Maintainability raises MTBF -> raises availability
What to actually do
| Practice | Which property | Effect |
|---|---|---|
| Structured logs, metrics, distributed tracing | Operability | Cuts detect and diagnose time |
| Runbooks for every alert | Operability | Any on-call engineer can act, not just the author |
| One-command rollback | Operability | Mitigation becomes seconds instead of a debugging session |
| Clear service boundaries | Simplicity | Failures stay local and explicable |
| Removing accidental complexity | Simplicity | Fewer places for bugs to hide |
| Backward-compatible schema changes | Evolvability | Deploys become independent and reversible |
| Feature flags | Evolvability | Decouples deploy from release; kill switch during incidents |
| Automated tests on the critical path | Evolvability | Changes are safe to make quickly |
Key takeaway
Availability is bought at design time, not at incident time. By the moment the pager fires, your MTTR is already fixed — determined by the observability, automation, and simplicity you did or did not build months earlier.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | Mentions monitoring and logging as a good practice. |
| L5 | Connects it to operations: "we need tracing to debug across services, and rollback so a bad deploy is a one-minute fix." |
| Staff+ | Derives it from the SLO: "our target allows 4 minutes a month, so no human can be in the recovery path — detection has to alert on user-visible symptoms and mitigation has to be automatic. Maintainability isn't hygiene here, it's what makes the availability number achievable." |
Next: the mechanisms that actually keep a system running when a component dies.