Reconstructibility

Short definition

The property of a system whose contracts between APIs, business rules and tests describing expected behaviour are identifiable and separated enough for a team to know how to rebuild it elsewhere, in another technology.

Full definition

The word circulates in several senses outside this context. In operations, it designates the ability to regenerate an environment identically from its sources and its configuration. In archiving and data science, it designates the possibility of recovering a datum or a result from what has been kept.

In the articles on this blog, the term designates a property of understanding, not of tooling: a system is reconstructible when you would know how to rebuild it, which presupposes knowing where the borders are — where an interface's contract runs, where the business rules live, which tests state expected behaviour rather than current implementation. The reconstruction doesn't have to be carried out: it serves as a control question, asked in place of "does it work?".

The normative sense and field usage diverge on one point. The norm would want identical reconstruction, down to the detail of the implementation. In the field, the question asked is weaker and more useful: would you know how to obtain the same behaviour by other means, starting again from what the system says about itself?

Usage in the field

The term comes into play as a quality criterion for development assisted by an assistant, where delivery speed no longer says anything about mastery. It also serves in architecture decisions — imposing contracts between APIs, writing the test pyramid before developing, refusing to let the business logic be scattered through the endpoints — and in end-of-project reviews, as the question that replaces the functional demonstration.

Synonyms and variants

"Would I know how to rebuild it?" — the interrogative form is the term's ordinary usage. Attested variants: "having handles on the system", "anchor points", "lines of separation".

Not to be confused with

• Understanding debt — the liability accumulated by a team on a system it can't explain; reconstructibility is the corresponding asset, and a team may have neither on a system it hasn't touched yet.
• Build reproducibility — the property of a manufacturing chain that produces the same artifact from the same inputs; it bears on tooling and is verified automatically, without any human having understood what the system does.
• Portability — a piece of software's ability to run on another environment without being rebuilt; it avoids reconstruction instead of making it possible.
• Architecture documentation — a description of the system's state as it is; it can be complete and leave a system nobody would know how to rebuild, just as it can be missing on a system whose tests are enough to state the behaviour.
• Technical debt — a design weakness whose handling has been decided and budgeted; a system can be heavily in debt and perfectly reconstructible, since one qualifies the design and the other what you can say about it.

Examples

"If tomorrow I have to extract this application into another technology, I know where the contracts are, where the business rules are, where the tests that describe expected behaviour are." — the reference usage, applied to an application developed with an assistant.

Refusing a full DDD approach on a project that doesn't warrant it, while refusing to let the business logic be scattered through the endpoints, is a reconstructibility trade-off: you aren't looking for purity of the model, you are looking for identifiable lines of separation.

Ambiguities / debates

The scope aimed at isn't settled: rebuild the behaviour, rebuild the architecture, or rebuild the code. The sense retained here is the first.

Verification even less so. Nobody rebuilds in order to check they would have known how, which leaves the criterion as a question asked in good conscience — and therefore exposed to the complacency of whoever answers it.