Your controller platform can compile generic bodies either way, with one default for every team: what decides which default you set?

A platform team owns the toolchain for a fleet of constrained field controllers and can set, once and for everybody, how generic bodies such as the telemetry decoder are compiled: a copy generated per sample type, or one shared body that receives the type's operations in a table. The source does not change either way. What makes this a lead's decision rather than a compiler flag is that the default propagates into what every team distributes, what a release means, and which choices remain reversible. ## The variable that actually decides it Is the set of type arguments **closed at build time**? - **Closed** — every sample type a decoder is used with is visible to the build, in repositories you build together. Generation is available. Whether it is worth it is then a genuine trade. - **Open** — sample types arrive from modules loaded in the field, from partner teams' artifacts, or from configuration read at start-up. Generation is not available for those arguments at all. No profile changes this, because there is no build in which the copy could have been produced. Everything else is secondary to that question, and a surprising number of platform debates never ask it. ## The inputs, in the order to weigh them 1. **Openness of the argument set**, as above. If it is open, the shared body is not preferred, it is required for that part of the system. 2. **What you distribute and who can rebuild.** Generation puts your generic bodies into consumers' builds in re-compilable form, which means their build compiles your code, a change inside a body is a rebuild for everyone, and the body's internals are readable. If some consumers ship images you cannot make them recompile on demand, that is close to disqualifying. 3. **Where the operations run.** Two operations per sample across a large window in every frame is where generated copies pay off; two operations per frame during setup is where the difference vanishes into noise. 4. **What the device can hold.** Generation multiplies emitted bodies by the number of distinct arguments, and a constrained controller has a real ceiling. This belongs on the list as a constraint to monitor, not as the deciding argument. ## Why it is a platform decision and not a per-team one A default is not merely advice. It determines the shape of every artifact teams publish to each other, so two teams on different strategies discover it the first time one tries to link the other's library with its own sample type. Consistency also owns the tooling: profiling, image-size budgets, and build-time dashboards are read differently under each strategy. Letting each team choose gives the platform both bills and neither benefit. ## The hybrid, and the rule it needs Most mature answers are hybrid: generate copies for a short, enumerated list of hot argument types, share the body for the rest. The mechanism is easy; the governance is the hard part. Without an explicit admission rule, every team argues that its own type is hot, the list grows monotonically, and the platform drifts into full generation without ever deciding to. A workable rule names who may add an entry, what evidence is required (a profile, not an intuition), and — the part usually forgotten — what causes an entry to be **removed**. ## What the default commits you to | | reversible later | sticky once published | |---|---|---| | source code | fully — no program text encodes the strategy | — | | internal binaries you rebuild | fully | — | | artifacts already distributed | — | consumers' builds already generate copies, or hold a binary with no re-compilable body | | supported argument set | — | consumers depend on what you enumerated | That asymmetry is the real commitment. Reversing the default costs nothing for code you still compile yourself, and costs a coordinated migration for everything you have already published under the old one. ## Signals that you chose wrong - Build times growing with the number of argument types rather than the amount of source, past the point teams tolerate. - Images running against the controller's ceiling, with the growth traceable to near-identical bodies. - Profiles dominated by operation calls inside per-sample loops, under a shared default. - Teams routing around the default — hand-duplicating a decoder per sample type by copy-paste — which is the clearest sign the default does not fit the work. ## What an interviewer is checking That you lead with the structural question instead of the performance one. A candidate who opens with "generated copies are faster, so generate" has skipped the only input that can make the decision for them. The strong answer asks whether the argument set is closed, then what ships and who can rebuild, then where the operations run; proposes a hybrid with an explicit admission rule; and states plainly which parts of the decision stay reversible and which do not.