Three teams each hand-maintain their own telemetry message types; what do you weigh before making one generated description mandatory?
answer
- a shared interface needs an editor
- the generator becomes infrastructure
- one change stops three builds
- what the notation cannot say
- generate alongside before switching
basics
~20 sWeigh who owns and reviews the description, whether the generator is maintained infrastructure or a weekend script, what happens the day one bad description change breaks three builds at once, whether the notation can express what the odd team needs, and how you would walk it back.
solid answer
~50 sThe mechanism is not in doubt — one description generating three outputs removes the duplication. The commitment is. You are making the description a **shared interface with an owner**: someone reviews every change, someone is on the hook when a change breaks three builds in the same hour, and the generator becomes infrastructure with a maintainer, a release process and a support burden. Ask whether the notation can express the one team's awkward requirement, and what the escape hatch is when it cannot — an extension seam, or a fork that quietly restores the duplication. Ask what the migration looks like: generate alongside the hand-written types first and compare, rather than switching. And ask how you exit: because the generator emits ordinary readable source, a team can adopt its last output by hand, which makes the bet reversible and therefore easier to make.
go deeper
Understand the appeal first: when three copies of the same message shapes exist, they agree until someone edits one, and a single description removes that possibility.
Be able to state the mechanism and its two direct costs: every consumer now depends on the generator to build, and every change to the description reaches all of them together.
Show the migration you would run: generate alongside the hand-written types, compare member by member, adopt one consumer at a time, and write down where hand-written additions are allowed to live.
Own the commitment. Name the editor of the description, the maintainer of the generator, the blast radius of a bad change, the expressiveness ceiling, and the exit that makes the bet reversible.
## What the proposal actually is Three teams hand-maintain types for the same telemetry messages. The types agree today because people are careful, and they will disagree next quarter because people are busy. Writing the shapes once in an external description and generating each team's source from it fixes the duplication. That part is not the hard question, and a lead who only argues that part has not understood the decision. The decision is that the description becomes a **shared interface between three teams**, and the generator becomes a piece of infrastructure all three depend on to build. Both of those are organisational commitments with owners, costs and a failure mode, and they outlast whoever proposed them. ## What you are signing up for 1. **Ownership of the description.** Who reviews a change to it? A change is simultaneously a change to three codebases, so the review has to be able to see all three consequences. If the answer is "whoever is fastest", the single source of truth has no editor. 2. **Ownership of the generator.** It needs a maintainer, a release cadence, a way to pin a version, and someone who answers when it fails on a machine it has never run on. A generator that is one person's script is a single point of failure that now gates three builds. 3. **Blast radius.** The same property that makes generation valuable — one change reaches every consumer at once — means one careless change stops three teams at once. That is usually still the right trade, because the alternative is three silent divergences instead of one loud stop, but it must be said out loud rather than discovered. 4. **An expressiveness ceiling.** The notation will not express something one team needs. What happens then is the whole game: an extension seam that gives hand-written code a legitimate home, a description feature added for everyone, or a fork that restores the duplication while keeping the ceremony. ## Weighing it honestly | Question | Points toward adopting | Points against | |---|---|---| | Do the shapes genuinely have to agree? | They are one pipeline's messages | Teams overlap only incidentally | | Who edits the shapes? | A small, identifiable group | Everyone, constantly, independently | | Is there a generator owner? | A team that will maintain it | One enthusiastic individual | | Do the consumers' needs converge? | Near-identical usage | One consumer is structurally different | | Can builds tolerate a shared dependency? | Yes, already shared | Each team builds in isolation by design | ## Making the bet reversible A principal-level answer usually includes how to make the decision cheap to undo: 1. **Generate alongside, do not switch.** Produce the generated types next to the hand-written ones and compare them, member by member, for a few weeks. The differences that show up are the requirements the description did not know about. 2. **Adopt one team at a time**, starting with the one whose usage is most typical, so the notation is stressed by a real consumer before it is mandatory for all. 3. **Keep the emitted source ordinary.** Because a generator emits readable code, the exit is real: if the generator becomes unmaintainable, a team adopts its last output by hand and continues. Say this early — it converts the proposal from an irreversible platform decision into a reversible one, which is usually what makes it approvable. 4. **Write down the seam and the ceiling** before adoption: where hand-written additions go, and what kinds of requirement will be refused as description features. Unwritten, both become arguments during an incident. ## When the answer is no It is a real answer, and knowing it is what separates judgment from enthusiasm: - The three teams' shapes only look similar; unifying them would invent a shared abstraction nobody asked for and each release would negotiate three sets of requirements. - Nobody will own the generator, and an unowned dependency in three build paths is worse than duplication you can see. - The duplication is small and stable, and the cost of coordinating a shared description exceeds the cost of the occasional divergence. The measure of the answer is whether you name the ownership question, the blast radius, the expressiveness ceiling and the exit — not whether you conclude yes.
- One team's requirement cannot be expressed in the description. What are the honest options?Three: add the feature to the description so every consumer carries it, give that team an extension seam where hand-written code lives beside generated output, or accept that this consumer stays outside. The one to refuse is a private fork of the generator, which keeps all the coordination cost and quietly restores the divergence you adopted it to remove.
- How do you argue this to a team that does not want a shared dependency in its build?Name the exit, not the benefit. The generator emits ordinary source, so the worst case is that the team adopts the last generated output by hand and continues from there. A reversible dependency is a different proposition from an irreversible one, and it is usually the reversibility, not the duplication argument, that settles it.
- What is the first sign the adoption is going wrong?Description changes that exist only to serve one consumer, arriving faster than the shared ones. That is the notation becoming a union of special cases, and it predicts the day when nobody can change the description without negotiating with three teams. The remedy is the seam, used deliberately, rather than more description features.
saying these in an interview costs you the question
- Argues only that duplication is bad and never names an owner
- Treats the generator as a script rather than maintained infrastructure
- Ignores that one description change can stop every build at once
- Has no answer for a requirement the notation cannot express
- Switches all three teams over in one change with no comparison period
- Presents the decision as irreversible when the emitted source makes it reversible