Recognizing Change Points

Introduction

Change points are the heart of pattern selection. Every GoF pattern encapsulates "what varies." The skill is not memorizing patterns — it is identifying where variation occurs, with evidence. Get the change point right and the pattern almost picks itself.

This lesson teaches a four-question framework: What varies? When did it last change? Who asks for the change? What is the cost of waiting? Apply it before reaching for any pattern, and you will eliminate most premature abstractions.

The story

A platform team at a marketplace startup spent two weeks debating which patterns to apply to their pricing engine. A staff engineer ran git log on the file: it had changed 47 times in eighteen months — 41 of those changes were to country-specific rules and 6 to rounding logic. The decision became obvious: Strategy for country rules, leave rounding inline. The two-week debate ended in twenty minutes. Evidence beat opinion.

The business problem

Wrong change points waste engineering time and hide the real seams where the business actually varies:

• Abstracted stability: modules that never change get interfaces; modules that change weekly stay monolithic.
• Design review gridlock: teams debate patterns for days when git log would settle it in minutes.
• Missed roadmap risk: upcoming product changes hit code with no seam because history looked quiet.
• Incident repeat: the same config or conditional breaks every release — a change point nobody named.
• Refactor waste: "great refactors" ship twelve interfaces when four had evidence behind them.

The problem teams faced

Without change-point analysis, teams guess instead of measure:

• Engineers predict where variation will occur instead of measuring where it has.
• Patterns land at "interesting" code rather than at proven variation axes.
• Git history, product roadmap, and incident data sit unused in design debates.
• Roadmaps reveal upcoming change points the codebase is not ready for — discovered too late.

Understanding the topic

Four evidence sources reveal where variation lives. Combine at least two before introducing a pattern:

• Git history — empirical record of what actually changed and why (commit messages cluster by reason).
• Product roadmap — declared future change points before history exists.
• Incident postmortems — failures expose hidden change points (config, flags, conditionals).
• ADRs — where the team commits to a change-point hypothesis that can be falsified later.

Internal architecture

The four-question framework — run this before any pattern-introducing refactor:

1. WHAT varies?     → algorithm, data source, channel, identity, lifecycle state
2. WHEN changed?    → git log --since=1.year -- path/to/file.ts
3. WHO requests it? → product, compliance, ops, customer support
4. COST of waiting? → revenue, audit risk, on-call burden, lead time

Score ≥ 3 strong signals  →  apply the smallest fitting pattern
Score < 2                 →  wait; inline code is correct today

Visual explanation

Three diagrams operationalize change-point thinking. The first is the four-question scoring framework. The second shows how evidence sources combine. The third maps a confirmed change point to the right pattern family.

Informative example

Pricing engine analysis — the marketplace story in code. Git evidence drives the seam:

// Before: one file, 47 commits in 18 months — 41 touched country rules
class PricingEngine {
  calculate(cart: Cart, country: string): Money {
    if (country === "US") return usRules(cart);
    if (country === "DE") return deRules(cart);
    if (country === "IN") return inRules(cart);
    // ... 12 more countries, changes every sprint
    return baseRules(cart); // rounding — only 6 commits ever
  }
}

// After: Strategy ONLY at the proven change point
interface CountryPricing { calculate(cart: Cart): Money; }

class PricingEngine {
  constructor(
    private byCountry: Record<string, CountryPricing>,
    private rounding: (m: Money) => Money, // inline — low churn
  ) {}
  calculate(cart: Cart, country: string): Money {
    const raw = this.byCountry[country]?.calculate(cart) ?? baseRules(cart);
    return this.rounding(raw);
  }
}

# Change-point git commands — run before design review
git log --oneline --since=1.year -- src/pricing/engine.ts
git log --follow -p --since=6.months -- src/pricing/engine.ts | less
git shortlog -sn -- src/pricing/engine.ts   # who touches this file?
git log --grep="country" --oneline -- src/pricing/engine.ts

Notice what did not get abstracted: rounding logic changed six times in eighteen months — not enough evidence for a pattern. Country rules changed forty-one times — Strategy earned its cost.

Execution workflow

Real-world use

Google and Meta design docs require "what varies?" sections. Kubernetes rejects PRs that abstract without documented change-point evidence. Adam Tornhill's hotspot analysis in Your Code as a Crime Scene formalizes git-churn-as-change-point-detection. Conway's Law adds another lens: team boundaries become change points because separate teams change separate code on separate schedules — when the org reorganizes, your seams may need to move too.

Production case study

A SaaS platform planned a "great refactor" of their order service — initial design proposed fourteen new interfaces and six patterns:

• Process: change-point analysis first — git log cluster review plus Q3 roadmap walkthrough.
• Finding: only four of fourteen proposed interfaces had historical or roadmap evidence.
• Decision: ship four patterns at proven seams; defer the other ten with documented kill-switch dates.
• Outcome: refactor shipped in 3 weeks instead of 12; codebase stayed understandable; on-call tickets unchanged.
• Lesson: evidence shrinks designs. Patterns that survive analysis are the ones that earn their cost.

Trade-offs

• Pro — Empirical: decisions based on data depersonalize design reviews.
• Pro — Defensible: easy to justify to skeptical seniors and auditors.
• Pro — Anti-over-engineering: patterns appear only where variation is proven.
• Con — Historical bias: git log shows the past; combine with roadmap for the future.
• Con — Greenfield blind spot: new code has no history — use product knowledge instead.
• Con — First-time cost: thirty minutes to learn the git workflow; pays back on the first debate it ends.

Decision framework

• Always run before pattern-introducing refactors on code older than three months.
• Always run when a teammate proposes heavy abstraction in design review — ask for git evidence.
• Combine git + roadmap when history is quiet but three or more committed features will touch the same module.
• Skip on greenfield day one — use product knowledge; revisit after the third repetition.
• Skip for hot-fixes — patch first, analyze change points in the post-incident refactor.
• Review quarterly — change points disappear when products sunset or markets exit; remove patterns whose axis died.

Best practices

• Cluster commit messages by reason changed, not by file or author — the cluster is the change point.
• Write the variation axis in the ADR before naming the pattern: "per-country pricing" not "Strategy."
• Map incident root causes to change points — config files that change in 30% of incidents are hidden seams.
• Use Tornhill-style churn maps for large repos — color files by change frequency before major features.
• When roadmap and git disagree, trust roadmap for forward-looking seams and git for what's real today.
• One pattern per change point — do not combine multiple axes in one refactor sprint.

Anti-patterns to avoid

• Abstracting every conditional because it "might" vary someday — that is speculative generality.
• Ignoring git log because "we know better" — opinion loses to forty-one commits on country rules.
• Placing Strategy at rounding logic because it sits in the same file as pricing — wrong axis.
• Running change-point analysis once and never revisiting when the product pivots.

Common mistakes

• Treating roadmap slides as evidence without committed engineering work behind them.
• Confusing file churn with reason churn — a file may change often for unrelated reasons.
• Missing change points in configuration, feature flags, and environment variables.
• Forgetting Conway's Law — org reorgs move change points; patterns must follow or be removed.

Debugging tips

• If a pattern feels unused, re-run git log — the axis may have stabilized or moved to another file.
• When incidents repeat in the same conditional branch, that branch is an unnamed change point.
• Diff production vs staging config change frequency — static-looking config often changes under incidents.
• Ask customer support which requests require code changes — they know change points product managers miss.

Optimization strategies

• Build a team habit: design review starts with "show me the git log" for any new interface proposal.
• Maintain a living change-point inventory doc — axis name, evidence source, pattern chosen, last reviewed date.
• For interviews, prepare the pricing engine story with real numbers (47 commits, 41 on one axis).
• Automate churn reports in CI — flag files in the top decile of change before major features land.

Common misconceptions

• Many developers believe change points are only for legacy code. In reality, greenfield code needs roadmap-based change points from day one on compliance and multi-tenant seams.
• Many developers believe one git log pass is enough. In reality, change points evolve — quarterly review removes patterns whose axis disappeared.
• Many developers believe change points equal microservice boundaries. In reality, most change points are in-process seams; network boundaries are a separate decision.
• Related: Hotspot analysis (Tornhill) and Conway's Law — formal and organizational lenses on the same idea.

Advanced interview questions

Summary

You can now find change points with evidence: git clusters, roadmap cross-check, four-question scoring, and pattern family selection. Tell the pricing engine story with numbers — forty-one commits on one axis, Strategy in twenty minutes. If you can do that without notes, you own this lesson.