Knowledge Deprecation

Advice about an architect's learning is almost all about acquisition. The harder half is subtraction. Currency is a recurring cost paid out of a fixed weekly budget, and an architect who never retires anything ends up claiming breadth they are not paying for.

Price it first. Genuine currency in one technology means running it, reading its release notes and following its issue tracker: roughly 2 hours a week, so on the order of 100 hours a year per area. On a realistic 5 to 6 hours a week of learning time, that supports about three deep areas plus shallow recognition of many. A claim to be current in eight areas is a claim to spend 800 hours a year.

Why it matters

Stale knowledge is not dangerous because it is wrong. It is dangerous because it is still fast. The answer from the technology you stopped deploying in 2021 arrives before the slower correct one, and in a room where you are the senior voice, nobody checks a number an expert says quickly. The bill is a quota memorised in 2021 quoted in 2026, a price per GB that moved twice, or a limit the vendor raised two releases ago.

The second cost is opportunity: each area retained is an area not added, and without deliberate retirement the portfolio is set by the order in which you encountered things.

Implementation patterns

• Split every body of knowledge into invariants and interfaces. Invariants are behaviours that hold wherever the same physics applies: write amplification in a log-structured store, queue latency near saturation, what a replica does when the leader is partitioned but alive. Interfaces are flags, operator semantics, quota tables, console layouts. Keep invariants, retire interfaces.
• Transfer check. Take the last three times you used the knowledge. Does each conclusion survive swapping the vendor? If it depended on product-specific behaviour, you are asserting something you have not verified in years.
• Correction check. In the last three design reviews where you invoked it, did someone with current hands-on experience correct a detail? Two of three is the signal to retire.
• Replace memory with a lookup habit for anything versioned, priced or quota'd: open the current documentation during the meeting. Memory is for behaviour, documents are for numbers.
• Write the invariant down in your own words when you retire the interface, or the useful half leaves with the useless half.

Industry example

GitLab's January 2017 database incident produced knowledge of both kinds. Its published postmortem records that the nightly pg_dump to object storage had been failing because the client version did not match the server version, and that the failure notifications never reached anyone. The invariant is permanent: a control that reports nothing when it fails is not a control, so verification must be positive - a successful restore recorded as a signal - rather than the absence of an error. That still predicts behaviour in 2026 on any backup, cron job or compliance check. The interface half - which client versions refuse which server versions - is obsolete product surface, and anyone who kept it instead has the wrong half.

Failure scenarios

• The confident stale number, stated quickly and unchallenged, which propagates into a capacity plan.
• Over-pruning into abstraction: retiring all hands-on currency leaves you unable to judge whether a vendor's claim is plausible.
• Retiring the interface and the invariant together, which is what happens when the lesson was never written down.

Trade-offs

Retirement buys budget for the areas that matter now and costs the standing deep expertise confers, a real loss where authority runs on it. Keeping an area buys a credible seat in that domain's reviews for 100 hours a year. Decision rule: keep deep currency where you are the last line of review and a wrong call is expensive to reverse; retire where the cost of a wrong recalled number exceeds the cost of looking it up.

When not to use it

If you are the only operator of a technology in production, the currency cost is part of the job until someone else owns it. Keep rarely used but high-consequence skills current even at a poor hours-to-use ratio — reading a query plan, reasoning about durability settings — because the alternative is being unable to check someone else's claim. And in a new domain, add before subtracting; a thin portfolio does not need pruning.

Interview question

Q: "Name a technology you were genuinely expert in and no longer keep current. What did you keep from it, what did you drop, and how do you know the part you kept is still true?"

What a strong answer covers: a clean split between a transferable invariant and discarded product surface; the test that told them apart; a specific stale fact they were caught on; and the budget arithmetic that forced the choice.

Quick check

Quiz: What distinguishes knowledge worth keeping from knowledge worth retiring? Invariants predict behaviour in systems you did not learn them on; interface knowledge — flags, quotas, console layouts — predicts nothing outside the product and belongs in a live lookup.

Flashcard: Roughly what does currency in one technology cost per year? On the order of 100 hours, which is why a 5 to 6 hour weekly learning budget supports about three deep areas.