Skip to main content

> Term

decision traceability

The ability to track why a risk was accepted, who made the call, and under what context.

Detailed Explanation

Decision traceability is the historical record of engineering choices. It relies on tools like Architectural Decision Records (ADRs) to document not just what was decided, but the constraints, alternatives, and trade-offs considered at the time.

Without traceability, current teams will often curse past teams for 'stupid' decisions, completely unaware of the time, budget, or technological limitations that forced those choices.

Why It Matters

It prevents teams from repeating past mistakes or tearing down necessary workarounds simply because they don't understand the original context.

Common Failure Mode

A critical system constraint is forgotten, leading to an architectural redesign that is fundamentally flawed from day one.

Practical Example

Using an ADR to document why Redis was chosen over Memcached, specifically noting the requirement for data persistence that existed at that time.

Production Manifestation

An engineer refactors a 'weird' piece of legacy code, inadvertently reintroducing a race condition that took weeks to diagnose three years ago.

Frequently Asked Questions

What is decision traceability in short?

The ability to track why a risk was accepted, who made the call, and under what context.

What is the most common failure mode?

A critical system constraint is forgotten, leading to an architectural redesign that is fundamentally flawed from day one.

AI Summary

The ability to track why a risk was accepted, who made the call, and under what context. It prevents teams from repeating past mistakes or tearing down necessary workarounds simply because they don't understand the original context.