skip to content

Why block new services at creation on a conformance rule while only scoring the services that already exist?

level: principalimportance: nice to knowfreq 33%

answer

  1. who is standing in front of the gate
  2. what remedy that person actually has
  3. free at creation, retrofit afterwards
  4. stop the growth, then buy down the stock
  5. count the backlog, not the percentage

basics

~20 s

Because conformance is nearly free at creation and expensive to retrofit. A new service can be scaffolded conformant immediately, so blocking is fair; an existing one would need unfunded rework, so the same rule only reports.

solid answer

~50 s

One rule and one definition of conformant, with the outcome selected by the age of the subject - because the remedy available to the blocked person is completely different in the two cases. At creation, whoever is blocked can regenerate from the template and be done in minutes. On a five-year-old service, the person blocked is usually someone fixing an unrelated bug, and stopping them buys nothing while spending the gate's credibility. So the same evaluation writes a scorecard entry for the existing estate, which makes the non-conformant population visible, countable and assignable, and you buy it down with funded work instead of ambushing whoever pushes next. The judgment to defend out loud: you are accepting a known non-conformant population for a period in exchange for guaranteeing it stops growing. Say that explicitly, give the scorecard an owner and a trajectory, and it is a strategy rather than a dashboard.

go deeper

for a junior

Know the shape of the idea: the same rule can block one change and merely record another, and which it does depends on what the person standing in front of it can realistically do about the failure.

for a middle

Be able to explain the mechanics - one evaluation, one definition of conformant, outcome selected by the subject - and why writing the blocking path and the reporting path as two implementations lets them drift apart.

for a senior

Show you have run this: how you define which services count as new, how you keep the scorecard honest with absolute counts, and what you do when a team routes around a rule they cannot afford to satisfy.

for a principal

Own the acceptance. You are choosing to live with a known non-conformant population in exchange for capping its growth - name the owner, the trajectory and the review point, and record it as an accepted gap rather than letting it read as coverage.

## The two populations are not alike When a conformance rule is written - required ownership metadata, a template-version floor, a licence-class constraint on distributed artifacts - it lands on two populations that look identical to the policy engine and are nothing alike in practice: - **Services that do not exist yet.** Conformance costs approximately nothing, because the scaffolder produces it. The person in front of the gate is creating something and has the whole thing in their hands. - **Services that already exist.** Conformance costs a retrofit that nobody planned, sized or funded. The person in front of the gate is usually not the person who would do that work, and is usually there for an unrelated reason. The rule is the same. The **remedy available to the blocked party** is not, and that asymmetry is the entire argument. ## Why blocking the existing estate is a bad trade Block at merge time on an old service and you interrupt whoever pushed next - frequently someone fixing a production bug, occasionally someone fixing the very incident the policy exists to prevent. They have three options: do unrelated work they were not funded for, find the exception path, or route around the gate. Two of those three damage you, and all three teach the organisation that the gate fires at random times against people who cannot fix it. A gate's authority is a finite resource and this is the fastest way to spend it. The reporting outcome, by contrast, costs the existing estate nothing on the day it ships and gives you the thing you actually need: an enumerated, assignable list of non-conformant services. You cannot plan work you cannot count. ## One evaluation, two outcomes The implementation discipline matters as much as the policy. Keep **one** evaluation and **one** definition of conformant; only the outcome is selected by the subject. The moment you write "the creation check" and "the scorecard check" as two implementations, they drift, and teams discover services that pass one and fail the other. When that happens nobody trusts either number, and the scorecard becomes unquotable in exactly the conversation it was built for. ## Defining "new" so it cannot be gamed The split needs a crisp subject boundary or it becomes a loophole. Define newness by the **catalog entry's identity**, not by the repository: a new catalog entry is a new service and is blocked; a rewrite under an existing entry stays on the scorecard. If you define it by the repository, teams learn that a fresh repository escapes the scorecard, or that deleting and recreating an entry is how you dodge the blocking path. Neither lesson is one you want taught. ## Keeping the scorecard from becoming furniture A scorecard with no owner and no target is a dashboard, and dashboards are ignored on a predictable schedule. Three things keep it alive: - **An owner and a trajectory.** Someone is accountable for the number moving, and there is a stated target date or rate. - **Absolute counts, not percentages.** The percentage improves on its own as conformant new services are created, which flatters you while the backlog sits exactly where it was. Report the count of non-conformant services; report the percentage only alongside it. - **Funded remediation.** The retrofit work is real work. If it is never on anyone's plan, the honest position is that you have accepted the gap, and you should say so rather than leaving a red number visible for two years as though it were about to change. ## The judgment you are actually defending Asked this in an interview, the answer that lands is not "blocking everyone is too disruptive." It is: *I am deliberately accepting a bounded, enumerated non-conformant population, in exchange for a guarantee that the population stops growing, and I am recording that acceptance where the organisation can see it and revisit it.* That is a decision with a named owner, a stated cost and a review point - which is what separates a strategy from a gate someone switched to warn mode because it was annoying people.

  • What stops the scorecard from being ignored indefinitely?
    An owner, a target and a forum where the number is read out. And report the absolute count of non-conformant services rather than a percentage: the percentage improves on its own as conformant new services arrive, so it can look like progress while the original backlog has not moved at all.
  • How do you keep 'new' unambiguous when a team rewrites an old service from scratch?
    Define the subject by the catalog entry's identity rather than the repository. A new catalog entry is a new service and is blocked; a rewrite under an existing entry stays on the scorecard. Otherwise teams learn that creating a fresh repository, or deleting and recreating an entry, moves them between the two regimes at will.
  • What does this split cost you if the two paths ever diverge in implementation?
    Teams find services that pass one and fail the other, and both numbers immediately lose credibility. Keep a single evaluation and a single definition of conformant; the subject's age selects only what happens with the result, never what the result is.

saying these in an interview costs you the question

  • Blocks the whole existing estate on day one
  • Writes two rules that drift out of agreement
  • Reports a percentage that self-improves with growth
  • Treats the scorecard as finished once it exists
  • Lets a new repository count as an existing service

context

resolving links…