A service replaced every null return with an empty-or-one-value context, yet call sites behave identically and the same bugs persist: what actually delivers the benefit?

## Why the migration produced nothing The container's value is not in the type, it is in the control flow the type makes possible. If every call site still asks `is there a value` and then forces the result open, the control flow is byte-for-byte what it was: a branch here, an early return there, a default written out three times with two of them subtly different. The signature is new and the failure modes are old. This is the most common way the idea gets adopted and then dismissed as ceremony. The team concludes the container does not help, when what actually happened is that only half the change was made - the half that costs nothing and buys nothing. ## The disciplines that do the work 1. **Keep it wrapped through the middle.** The container is created at the lookup that may find nothing and passed along, still closed, through every layer that does not care. Those layers transform inside it. None of them contains the word `empty`. 2. **Decide once, at the edge.** Exactly one place per use case turns the container into an answer - a response field, a rendered line, a default in a report. That place is chosen because it knows what nothing should mean there, and a different caller may choose differently. 3. **Treat a force-open as an assertion.** Allowed where emptiness is impossible by construction and visible within a few lines; never as the routine way values are read. Everything else goes through a transformation or a fallback. 4. **Never let the container itself be missing.** A container that can be absent is the original hazard plus a level of unwrapping - you must now check two things instead of one, and the outer check is exactly the one the migration claimed to remove. ## Where the container does not belong Over-application is the other way this goes wrong, and it is worth saying out loud in an interview, because it shows the judgment is real rather than enthusiasm: - **Arguments.** Wrapping a parameter asks every caller to build a container around a value it already has, to express something two separate entry points would express more plainly. - **Stored fields.** Data that may simply not be recorded is often better modelled by not recording it - a missing row, a separate record - than by putting a container in front of every read. - **Values that are always there.** Wrapping them adds noise and, worse, trains readers to skim past containers, which is precisely the habit that makes the real ones dangerous. - **Failures that carry a reason.** An empty says nothing about why. Where the caller must act differently depending on why, this is the wrong shape and no amount of wrapping will fix it. ## How to tell whether it worked Measure the call sites, not the signatures. Useful signals, in rough order of value: | signal | migration that worked | migration in name only | |---|---|---| | presence tests per call site | close to zero | roughly one, as before | | places that decide what nothing means | one per use case, at an edge | scattered through the middle | | force-opens | rare, each with a visible reason | the normal way values are read | | duplicated default values | one per use case | one per call site, drifting apart | | containers that may themselves be missing | none | present, and unremarked | A count of wrapped return types tells you only how much typing was done. ## Doing it without a big bang The realistic route is by boundary, not by repository-wide search and replace. Take one lookup, change its return, and then fix its call sites in the same change rather than leaving them for later - a half-migrated call site is the test-then-open pattern by definition, and half-migrations have a way of becoming permanent. Where the same value crosses several layers, start from the edge that has to answer and pull the container upward, because that is the direction in which the middle layers get simpler rather than noisier. ## What an interviewer listens for The weak answer is `they should have used it properly`. The answer that lands separates the type change from the control-flow change, names the specific call-site shapes to look for, states at least one boundary where the container should not be used, and gives a way to tell success from a rename - which is almost always counting what is left at the call sites rather than counting what was wrapped.