[Anchor Proposal]: TDD Hamburg School according to Ralf Westphal

[raifdmueller]

Proposed Term

TDD Hamburg School according to Ralf Westphal

Context (Optional)

No response

Pre-submission Checklist

• I have searched existing anchors and this term is not already included
• This term refers to a well-established concept (not something I invented)

[kuerm]

TDD, Hamburg Style

Details

Also known as
ACD (Analyze-Design-Code) approach, Ralf Westphal's TDD.

Core Concepts:

• Requirements Logic Gap
  Focus on bridging the gap between requirements and the logical implementation. This is the core concept.

• "Right from the start" philosophy
  Implement code correctly from the beginning to minimize or eliminate the need for subsequent refactoring

• ACD Cycle
  Analyze, Design, Code; a structured sequence that precedes the actual implementation

• Service-level testing
  Test the service logic behind the public API to remain independent of specific API technologies

That supports next concept:

• Minimal Mocking
  Use mocks as sparingly as possible

• IOSP (Integration Operation Segregation Principle) (not as important for Hamburg Style TDD but supports simple Unit Tests)
  A structural pattern used to separate logic (Operations) from the wiring of components (Integration)

• Deep Work over Small Steps
  Accept that some problems cannot be divided into tiny chunks; "do the homework" even if tests remain red for a longer period

Key Proponents
Ralf Westphal

When to Use:

• Non-incremental problem spaces
  When the problem domain is too complex to be solved through small, iterative Red-Green-Refactor steps

• Limited refactoring windows
  In environments where Business Owners or stakeholders do not allocate time for refactoring once functionality works

• Clean Architecture projects
  When strict separation of concerns and technology independence are primary goals

Where to add the source?

• https://ralfw.de/hamburg-style-tdd/
• https://ralfw.de/tdd-how-it-can-be-done-right/

[raifdmueller]

Hi @kuerm — thank you for the very thorough write-up, and for picking up on the suggestion from the live show. The detail and the source links are exactly the kind of contribution we hope for.

Before we add it, I want to be transparent about why I don't think it fits the Anchor slot yet, and propose a different home for it.

What makes something a Semantic Anchor

A semantic anchor has to activate a stable definition that already lives in the LLM's training data. The litmus test is the prompt:

What concepts do you associate with ''?

If a model — without any further context — comes back with the same set of core concepts, proponents and use cases that you would write into the anchor file, it's an anchor. If different models give vague or divergent answers, the term doesn't carry the activation, no matter how well-defined it is in a specific community.

The implication is harsh but useful: an anchor must work without its own explanation. The whole point is that you reference it in a prompt and don't have to repeat the definition.

Why "TDD Hamburg Style" doesn't pass that test (yet)

When I prepared a draft anchor I noticed I was leaning heavily on Ralf Westphal's own page (https://ralfw.de/hamburg-style-tdd/) for the wording. That's a warning sign: I wasn't recalling it, I was reading it. The same is true for ACD (Analyze-Design-Code) and IOSP (Integration Operation Segregation Principle) — both clearly defined, both attributable to Westphal/Lieser, but neither broadly enough recognised that an LLM consistently activates them from the term alone. London and Chicago/Detroit pass that bar; Hamburg, Munich and St. Pauli are regional Crafter-community vocabulary.

Adding "TDD Hamburg Style" as an anchor would lower the bar in a way that matters: future contributors and prompt authors would have to start checking whether each anchor actually activates, instead of being able to trust the catalog.

Where it does fit: as a Semantic Contract

Contracts are different. A contract spells out the recipe explicitly and composes existing anchors, so it doesn't depend on the LLM having seen the contract name before. We have several already (Specification, Architecture Documentation, Socratic Code Theory Recovery, …).

Based on your comment, here is a draft contract. It composes our existing TDD anchors (TDD London School, TDD Chicago School, Red-Green-Refactor) and inlines the Westphal-specific vocabulary (ACD, IOSP, "right from the start", service-level testing, deep work over small steps) instead of treating them as anchors:

---

TDD, Hamburg Style

Design-led TDD recipe by Ralf Westphal — close the requirements/logic gap before writing code, then test at service boundaries with minimal mocking. Use it when the problem is too complex for pure micro-step Red-Green-Refactor.

• ACD cycle (Analyze → Design → Code) precedes the test loop. First close the gap between requirements and logic by modeling the solution; only then code.
• "Right from the start" philosophy: aim to implement correctly the first time so refactoring is a correction, not a routine cleanup.
• Service-level testing: test behind the public API, independent of API technology, instead of at every internal method.
• Minimal mocking — closer to TDD, Chicago School than to TDD, London School.
• IOSP (Integration Operation Segregation Principle): a function is either composition (Integration) or logic (Operation), never both. Supports simple unit tests but is structural support, not the goal.
• Deep Work over Small Steps: accept that some problems cannot be sliced into tiny green-step increments. Stay red longer when the design demands it.

Composes: TDD, London School, TDD, Chicago School, Red-Green-Refactor.
Sources: https://ralfw.de/hamburg-style-tdd/, https://ralfw.de/tdd-how-it-can-be-done-right/

---

A few open questions before we'd merge this:

1. Activation check for "TDD Hamburg Style" / "Hamburg Style TDD" against GPT-5, Claude, Gemini — happy to be wrong about the activation. If two of three return the ACD cycle and IOSP unprompted, we should reconsider it as an anchor after all.
2. IOSP as its own anchor: this is the most promising candidate from the set — defined principle, documented attribution to Westphal/Lieser, even tooling (IospAnalyzer). If you'd like to propose IOSP separately, the contract above can later reference it as an anchor instead of inlining the definition.
3. Naming: "Hamburg Style" or "Hamburg School"? Westphal's page uses "Hamburg Style", which I'd lean toward.

Does the contract framing work for you? And would you be up for a separate IOSP anchor proposal?