skip to content

Your builds now compile the whole program ahead of time and strip unreached code — what do you standardize across teams?

level: principalimportance: should knowfreq 30%

answer

  1. visible, bounded, tested
  2. declare beside the code that needs it
  3. test the artifact you ship
  4. a wildcard cancels the win silently
  5. default plus a costed exit

basics

~20 s

Standardize three things: every place a target is chosen from data is declared and reviewable, acceptance suites run against the stripped artifact rather than the plain build, and opting out is explicit and costed rather than silent.

solid answer

~40 s

Once the build assumes it can see the whole program, any target chosen from data at run time becomes a liability that no test on the plain build will catch. The standard has to make that surface **visible, bounded and tested**. Visible: each dynamic resolution point is declared, next to the code that needs it, naming what it reaches and why. Bounded: broad catch-all declarations are treated as defects, because they retain most of what the pass was meant to remove. Tested: the release pipeline exercises the stripped artifact, since the unstripped one cannot reproduce the failure. Then set the trade explicitly — teams whose target set genuinely comes from data they do not own at build time should opt out with the startup and size cost stated, rather than discovering deletions in production.

go deeper

for a junior

Understand that a build which strips unused code changes what the team must write down, and that anything chosen by name at run time now needs declaring.

for a middle

Be able to explain why a wildcard declaration technically works and practically cancels the benefit the stripping was adopted for.

for a senior

Own the pipeline half: get acceptance traffic onto the stripped artifact, and use the resulting failures as the inventory of your service's dynamic surface.

for a principal

Set a default with a documented exit and a metric for surface growth, so the cost lands on the team choosing the mechanism rather than on whoever is on call.

## What actually changed Before, a program could summon any part of itself by name and the artifact contained everything it might summon. After, the build decides what the program can possibly use and deletes the rest. The lever is real — smaller artifacts and faster starts — and the bill is paid in a specific currency: **every target chosen from data must now be declared by hand**, because the build cannot infer it. A lead's job here is not to answer this for one service. It is to set a rule that many teams can follow without each of them learning it from an outage. ## The three things worth standardizing 1. **The dynamic surface is declared and reviewable.** Every point where the program resolves a target from data has a declaration that names what it reaches. The declaration lives beside the code that needs it, not in one central file, so it moves and dies with that code. 2. **The pipeline tests what ships.** Acceptance traffic runs against the stripped artifact. A suite that only ever exercises the unstripped build is proving something about an artifact nobody deploys. 3. **Opting out is explicit and costed.** Some services genuinely resolve targets supplied by data they do not own at build time. Let them step out, with the size and startup cost written down, rather than declaring a wildcard that keeps the pass running while cancelling its benefit. ## The arguments you will actually have - **"Just declare everything."** A broad declaration retains most of the program, so the build still takes the analysis time and the artifact keeps the bulk. It converts a visible failure into an invisible non-improvement, which is worse, because nobody revisits a problem that looks solved. - **"Turn the optimization off for now."** Reasonable as a migration state, dangerous as an end state, because the decision quietly reverses itself the moment the budget that justified the change is needed. - **"It works locally."** It always does. Locally is the unstripped build, and the unstripped build cannot exhibit the defect. This is the single most common way the failure reaches production. ## What to measure | Signal | What it tells you | What to do about it | |---|---|---| | Number of declared roots per service | How wide the dynamic surface is | Treat sustained growth as design debt, not paperwork | | Wildcard or catch-all declarations | The optimization is being cancelled quietly | Require a named owner and an expiry | | Share of releases tested on the stripped artifact | Whether the pipeline proves anything | Drive toward all of them before the rule is mandatory | | Services opted out entirely | Where the closed-world assumption does not fit | Revisit periodically; some become eligible as they change | ## The judgment, stated plainly This is a bet that the deployment's set of reachable code is knowable at build time. That bet is usually right and occasionally wrong, and where it is wrong it is wrong structurally — a service whose targets arrive with the data cannot be closed, and no amount of declaration discipline changes that. So the standard should be **a default plus a documented exit**, not a mandate. Default: closed, declared, tested against the stripped artifact. Exit: named, costed, revisited. What a lead is really buying is that the cost of the mechanism is paid **at design time by the team choosing it**, instead of at three in the morning by whoever is on call when a rarely taken path asks for something the build removed months ago. ## Sequencing the rollout - **Start with the pipeline change**, not the rule. Running acceptance suites against the stripped artifact surfaces the real inventory of dynamic surface across services, which is information you do not otherwise have. - **Then publish the declaration convention**, with the measured inventory as evidence that it is small enough to follow. - **Make it a gate last.** A gate imposed before teams can see their own surface produces wildcards, which is the outcome this whole standard exists to prevent.

  • What single pipeline change catches most of these failures before release?
    Run the acceptance suite against the stripped artifact instead of the plain build. The plain build cannot reproduce a deletion, so any suite that only exercises it is silent on exactly the class of defect the change introduced.
  • How do you stop the declared-roots list from becoming a dumping ground?
    Require every entry to name the code that needs it, keep it beside that code so it dies with it, and review growth as a metric. Treat wildcards as defects with an owner and an expiry, since a broad declaration retains most of what the pass exists to remove.
  • When is opting a service out the right call?
    When its set of targets genuinely arrives with data it does not own at build time, so the surface cannot be enumerated in principle. Opt out explicitly, record the size and startup cost, and revisit when the design changes rather than pretending a wildcard closed it.

saying these in an interview costs you the question

  • Declares a broad wildcard of roots and calls the problem solved
  • Mandates the rule before teams can see their own dynamic surface
  • Keeps testing the unstripped build because it is easier to run
  • Treats an opt-out as failure rather than a costed, revisitable choice
  • Assumes one central declaration file can be maintained by everyone