Semantic Anchors — Complete Reference

4MAT System of Instruction

4MAT Learning Cycle, McCarthy’s 4MAT

Establish relevance and motivation first. Why should the audience care? Connect the topic to their experience, problems, or goals before introducing new information.

Present the facts, concepts, and structure. The core content — definitions, models, theory, how the pieces fit together.

Show practical application. Demonstrate usage, walk through examples, let the audience try it hands-on. Translate theory into skill.

Explore extension, variation, and transfer. What happens at the edges? How does this apply to new situations? Encourage creative application and critical questioning.

The order matters — why before what prevents "so what?" disengagement; how before what-if prevents premature abstraction.

Each quadrant alternates between reflective observation and active experimentation, engaging different cognitive styles in one flow.

Innovative (Why), Analytic (What), Common Sense (How), Dynamic (What If) — every presentation serves all four instead of only the "analytic learner" that default lecture formats assume.

Bernice McCarthy ("The 4MAT System: Teaching to Learning Styles with Right/Left Mode Techniques", 1980; "About Learning", 1996)

Attention, Interest, Desire, Action

AIDA Funnel, Hierarchy of Effects (AIDA branch); variants: AIDAS (+Satisfaction), AIDCA / AIDCAS (+Conviction), AIDA-R (+Retention)

First capture awareness — a headline, hook, or visual that makes the audience stop and notice. Nothing else works until this stage lands.

Hold engagement by making the message relevant — speak to the reader’s problem, curiosity, or benefit so they keep reading.

Create wanting — turn "this is relevant" into "I want this" through benefits, proof, emotion, and addressing objections.

Prompt a single, clear next step — the call to action (buy, sign up, reply). Without an explicit ask, the funnel leaks at the end.

The stages are ordered and narrowing — each filters the audience to the next. The model’s value is forcing copy to do each job in turn rather than jumping to the ask.

AIDA is the best-known member of a family of step-models describing how persuasion moves a person from unaware to converted; it is a heuristic, not a measured cognitive law.

Commonly attributed to E. St. Elmo Lewis (1898), an American advertising advocate; popularised in 20th-century advertising and sales literature

Taxonomy of Educational Objectives, Cognitive Domain (Revised 2001)

Bloom’s Revised Taxonomy; Anderson & Krathwohl Taxonomy

A hierarchy of what a learner can do with knowledge, from lower-order to higher-order — Remember, Understand, Apply, Analyze, Evaluate, Create. Higher levels presuppose the lower ones.

Retrieve facts from memory — recall, recognise, list, name. The floor, not the goal.

Construct meaning — explain in one’s own words, summarise, paraphrase, give an example. Understanding is not yet mastery.

Use knowledge in a new situation — execute, implement, solve a fresh case. The first level that proves transfer beyond the example taught.

Break a whole into parts and see how they relate — differentiate, attribute, find the edge cases, trace cause to effect.

Judge against criteria — critique, weigh trade-offs, defend a decision.

Assemble parts into something new — design, build, generate a working solution.

Each level has its own measurable verbs, which is what turns a vague aim ("understand recursion") into a testable objective ("implement a recursive traversal", "analyse why this base case prevents infinite recursion").

Anderson & Krathwohl turned Bloom’s 1956 nouns into verbs and reordered the top two (the original ended Synthesis → Evaluation; the revision ends Evaluate → Create). They also added a second axis — the knowledge dimension (factual, conceptual, procedural, metacognitive) — yielding a two-dimensional taxonomy table.

The hierarchy is a design aid, not a strict ladder — real tasks mix levels, and Evaluate-vs-Create ordering is debated. Its value is forcing assessment above mere recall, not literal sequencing.

Benjamin Bloom et al. ("Taxonomy of Educational Objectives", 1956); Lorin Anderson & David Krathwohl ("A Taxonomy for Learning, Teaching, and Assessing", 2001 revision)

BLUF (Bottom Line Up Front)

Direct Answer Format, Conclusion-First Communication

State the main point, decision, or recommendation immediately

Most important information first, supporting details follow

Lead with what needs to happen or what was decided

Enable time-pressed readers to get key information instantly

Detailed rationale, data, and background come after the conclusion

Clear hierarchy enables readers to stop at their needed depth

No narrative buildup or delayed conclusions

Ideally, the BLUF itself is a single, clear sentence

US Military (Army writing standards), adopted broadly in business and government

Standardized in military communication where rapid decision-making is critical; now standard in business writing (McKinsey, consulting, executive communication)

Gutes Deutsch nach Wolf Schneider (Good German according to Wolf Schneider)

Wolf Schneider’s Writing Principles, Schneider’s Stilregeln

Prefer short, direct sentences over long, complex ones — every sentence should express one idea

Use active constructions; avoid passive voice and impersonal constructions wherever possible

Replace noun phrases (Nominalstil) with verbs — "wir entscheiden" instead of "eine Entscheidung wird getroffen"

Use specific, tangible words instead of abstract generalizations; prefer the particular over the general

Eliminate weak, redundant, or empty words (Füllwörter) that add no meaning — "eigentlich", "grundsätzlich", "im Grunde genommen"

Choose a common, familiar word over a foreign or technical term when both carry the same meaning

Vary sentence length consciously to create a natural reading rhythm; monotony fatigues readers

Every sentence should serve the reader; never write to impress, only to be understood

Wolf Schneider ("Deutsch für Profis", 1982; "Deutsch! Das Handbuch für attraktives Schreiben", 2005)

Inverted Pyramid Style

News Style, Front-Loading

Lead with the essential who/what/when/where/why, then present supporting detail in decreasing order of importance

The reader can stop at any point and still have the most important information — later paragraphs add depth, not prerequisites

Unlike a tight summary, the body may carry a long tail of quotes, background, and context that an editor (or reader) can cut from the bottom without losing the core

BLUF demands a short message with the bottom line up front; the Inverted Pyramid front-loads the conclusion but allows an extended, optional remainder

Minto’s Pyramid builds a complete, MECE argument the reader should follow fully; the Inverted Pyramid optimizes for skimming and early exit, not for completeness

Journalistic convention attributed to late-19th-century American wire-service reporting (telegraph cost and editing pressure); a standard taught in journalism and technical writing

MECE (Mutually Exclusive, Collectively Exhaustive)

Categories have no overlap - each item belongs to exactly one category

Categories cover all possibilities - nothing is left out

Systematic approach to structuring information and problems

Mutual exclusivity ensures no redundant coverage

Collective exhaustiveness ensures complete coverage

Unambiguous categorization with well-defined criteria

Can be applied recursively at multiple levels

Check both dimensions independently (exclusivity and exhaustiveness)

Barbara Minto (McKinsey & Company, late 1960s)

Myers-Briggs Type Indicator (MBTI)

MBTI, Myers-Briggs, Jungian Type Theory Applied, 16 Personality Types

The framework defines four preference dimensions, each with two poles:

The four dichotomies combine into 16 distinct type profiles (e.g., INTJ, ENFP, ISTJ, ESFP), each with characteristic strengths, blind spots, and communication preferences

Each type has a stack of four cognitive functions (e.g., dominant Introverted Intuition, auxiliary Extraverted Feeling for INFJs) that describe how information is processed and decisions are made

Type describes a natural preference, not a skill or fixed trait — people can and do use all functions, but prefer some over others

Understanding a team’s type mix reveals likely sources of friction (e.g., S/N conflicts over big-picture vs. detail focus) and natural collaboration patterns

Isabel Briggs Myers and Katharine Cook Briggs, building on Carl Gustav Jung’s theory of psychological types ("Psychological Types", 1921)

Developed during World War II to help women entering the industrial workforce find roles suited to their personality; officially published as an instrument in 1962 and widely adopted in organizational and educational settings

Plain English according to Strunk & White ("The Elements of Style")

Strunk & White, The Elements of Style, Plain Style Writing

Every word in a sentence should serve a purpose; cut words that add bulk without adding meaning — "the fact that" → "that", "owing to the fact that" → "since"

Prefer active constructions over passive; active voice is more direct, vigorous, and concise — "The dog bit the man" not "The man was bitten by the dog"

Prefer the particular and tangible over the vague and abstract; concrete details make writing vivid and persuasive

Rely on strong nouns and verbs rather than adjectives and adverbs; the right noun or verb makes modifiers unnecessary

The most important idea in a sentence belongs at its end — the position of greatest emphasis

Express coordinate ideas in similar grammatical form; parallelism aids comprehension and gives prose a pleasing rhythm

Remove weakening qualifiers like "rather", "very", "little", "pretty" — they dilute the force of the statement

Good writing is rewriting; a first draft is a starting point, not a finished product

William Strunk Jr. ("The Elements of Style", 1918); E.B. White (revised edition, 1959)

NVC, Problem Space NVC, Gewaltfreie Kommunikation (GFK)

Concrete, objective facts without evaluation or judgment. "The deploy failed three times this week" instead of "The deploy always fails."

Emotions arising from observations. "I feel frustrated" instead of "This is frustrating."

Universal human needs underlying feelings. Reliability, autonomy, clarity, safety. The real driver behind every request.

Specific, actionable asks (not demands). "Could we add a pre-deploy check?" instead of "Fix the deploy process."

Observe → Feel → Need → Request. Each step builds on the previous one.

Marshall Rosenberg ("Nonviolent Communication: A Language of Life", 1999)

The Minto Pyramid Principle according to Barbara Minto

Single key message at the top of the pyramid

Situation → Complication → Question → Answer structure for setting context

Mutually Exclusive, Collectively Exhaustive grouping of ideas

Each level answers "Why?" of the level above it

Arguments at the same level grouped deductively or inductively

Present conclusion first, then supporting arguments

One central idea supported by groups of three supporting ideas

Bottom Line Up Front - lead with the conclusion

Choose appropriate logic for horizontal grouping

Barbara Minto (McKinsey, "The Minto Pyramid Principle", 1987)

Rising Action Structure, Crisis-Driven Structure

Story begins in the middle of action — no leisurely setup; the protagonist is already in crisis

A series of escalating mini-crises (not a single inciting incident) each raising stakes higher than the last; no breathing room between them

Background and character development are woven into the action retrospectively rather than front-loaded

Each crisis forces the protagonist to make a consequential choice that inevitably leads to the next, larger crisis

The final, highest-stakes crisis where the central conflict is resolved

Short denouement after the climax; the curve descends steeply

Backstory is delivered only as needed to understand the next crisis — never as separate scenes

Named after German philosopher Johann Gottlieb Fichte; popularised in craft books by John Gardner and Janet Burroway

Five-Act Structure, Dramatic Arc, Dramatic Pyramid, Yorke’s Five-Act Structure

Establishes the setting, protagonist, and status quo; introduces the inciting conflict

A series of complications and conflicts build tension; protagonist pursues goal while antagonist force resists; stakes escalate

The turning point of maximum tension; the decisive confrontation or revelation that determines the outcome

Consequences of the climax unfold; loose ends begin to resolve; tension releases

Final equilibrium — either a restoration (comedy) or a tragic collapse (tragedy); loose ends are tied

The audience may know more than the protagonist, heightening tension — a hallmark of classical five-act drama

The protagonist’s fatal flaw that drives the tragic trajectory — central to Freytag’s original analysis of Shakespeare’s tragedies

Gustav Freytag ("Die Technik des Dramas", 1863); John Yorke ("Into the Woods", 2013) — modern expansion linking Freytag to neuroscience of narrative

Monomyth, Campbell’s Monomyth, The Writer’s Journey (Vogler adaptation)

The hero’s familiar environment before the adventure begins; establishes baseline and stakes

The inciting event that invites or compels the hero to leave the ordinary world

Hero’s initial hesitation or reluctance, adding realism and raising stakes

The hero encounters a guide who provides wisdom, tools, or confidence

Hero commits and enters the Special World of the adventure — point of no return

Hero navigates the unfamiliar world, building relationships and facing obstacles

The central crisis — a death-and-rebirth experience that transforms the hero

Hero survives the ordeal and claims a reward (knowledge, object, resolution)

Hero begins the return, often pursued by consequences of the ordeal

Final climactic test where hero is transformed — applying lessons from the journey

Hero returns to the ordinary world changed, bringing something of value back

Joseph Campbell ("The Hero with a Thousand Faces", 1949), Christopher Vogler ("The Writer’s Journey", 1992)

Four-Act Eastern Structure, 起承転結 (Ki-Shō-Ten-Ketsu), Kishōtenketsu

Introduce the characters, setting, and situation without conflict; establish the status quo with curiosity

Continue and expand on what was introduced; deepen the world, add detail, build the reader’s engagement; no conflict required

Introduce a surprising, unexpected element that recontextualises everything established so far; the "twist" is not a villain or conflict — it is a revelatory shift in perspective or a new element that changes meaning

Synthesise the introduction, development, and twist into a harmonious resolution; the new element from Ten is integrated, producing insight, beauty, or meaning

Unlike Western three-act structure, Kishōtenketsu does not require protagonist-antagonist conflict; tension arises from juxtaposition and recontextualisation, not opposition

The structural heart is the Ten — the unexpected element that makes the reader re-read the Ki and Shō with new eyes

Nintendo game director Koichi Hayashida has cited Kishōtenketsu as the design philosophy behind Super Mario level structure

Classical Chinese (qǐ chéng zhuǎn hé) and Japanese (ki shō ten ketsu) poetic and narrative tradition; modern analysis by Tzvetan Todorov and narratologists studying non-Western story forms

Blake Snyder Beat Sheet, BS2, 15-Beat Sheet

A single scene (p. 1) establishing the tone, mood, and "before" snapshot of the protagonist’s world

By page 5 someone (not the hero) articulates the film’s thematic argument — the lesson the hero must learn

Introduce hero in their ordinary world; plant every character and element that will pay off later

The inciting incident — life-changing event that kicks the story into gear

Hero hesitates; internal or external conflict about whether to take the leap

Hero makes a choice and enters the upside-down world of Act 2 — the new status quo begins

A secondary story (often a love story or mentor relationship) carrying the theme

The "promise of the premise" — deliver what the audience came for; poster scenes

A false victory or false defeat that raises stakes; hero goes from reactive to proactive

External pressure increases while internal doubts resurface

The worst moment — something is lost (or someone dies); the "whiff of death"

Hero wallows in despair; the last moment of hesitation before transformation

Inspiration strikes — the A story and B story merge; hero finds the solution

Execute the new plan; world is stormed, changed, and reset at a higher level

Mirror of the Opening Image — the world has changed; prove the theme was mastered

Blake Snyder ("Save the Cat!", 2005)

Harmon Story Circle, Dan Harmon’s Story Circle, Channel 101 Narrative Structure

Begin with a character in their zone of comfort — the ordinary world; the audience must identify with them

The protagonist desires something; this desire drives all subsequent action

Protagonist crosses into an unfamiliar situation in pursuit of the need; the adventure begins

Protagonist must navigate and adapt to the new world — the main body of the story

Protagonist achieves what they were seeking (the "want"), but this is rarely the real satisfaction

The cost of getting what was wanted; a sacrifice is made — the price of growth

Protagonist carries their hard-won change back to the familiar world

The protagonist (and world) is transformed; the "need" is finally met, even if the "want" was different

Unlike linear structures, the circle implies that stories are cyclical — transformation restores balance at a higher level

Designed to work at any scale: one episode, one season, one film; each act is ~12.5% of the story

Dan Harmon (creator of Community and Rick and Morty); adapted from Joseph Campbell’s Monomyth

Setup-Confrontation-Resolution, Beginning-Middle-End, Aristotelian Three-Act Structure

Introduce protagonist, world, and status quo; ends with an Inciting Incident that propels the protagonist into the main conflict (~25% of story)

Protagonist pursues goal while obstacles escalate; contains Midpoint Reversal and All-Is-Lost moment; longest act (~50% of story)

Climax where protagonist faces the central conflict at maximum stakes, followed by denouement restoring a new equilibrium (~25% of story)

The triggering event that disrupts the protagonist’s ordinary world and sets the story in motion

The structural centre of Act 2 where the protagonist shifts from reactive to proactive stance

The low point immediately before the final push, where all seems hopeless

The decisive confrontation between protagonist and antagonist force resolving the central conflict

Aristotle ("Poetics"), Syd Field ("Screenplay"), Robert McKee ("Story"), Blake Snyder ("Save the Cat!")

Code Smells

Bad Smells in Code, Refactoring Smells

A surface indication in the code that usually points to a deeper design problem. Smells are heuristic: they are quick to spot, do not prove a defect exists, and are evaluated in context. A smell tells you where to look, not what to do.

Martin Fowler’s Refactoring (1999, 2nd ed. 2018, with the original smell chapter co-authored by Kent Beck) is the canonical catalogue. Each smell is paired with a refactoring that typically resolves it. Common groupings of Fowler’s 20+ smells:

Robert C. Martin’s Clean Code (2008), Appendix A "Smells and Heuristics", extends Fowler’s catalogue with additional smells organised by concern — Comments, Environment, Functions, General, Java, Names, Tests — about 65 heuristics in total. These are complementary refinements, not a replacement for Fowler’s set.

Kent Beck coined the term "code smell" in the 1990s; Fowler wrote the book that made it the standard vocabulary. "It just feels wrong" became expressible and teachable.

Kent Beck (coined the term), Martin Fowler (Refactoring, 1999, 2nd ed. 2018 — canonical catalogue), Robert C. Martin (Clean Code, 2008, Appendix A — extended enumeration).

Cohesion Criteria (Constantine & Yourdon)

Levels of Cohesion, Cohesion Scale, Module Cohesion Types

Elements are grouped arbitrarily with no meaningful relationship. Typical sign: utility classes or grab-bag modules.

Elements perform similar activities selected by a control flag. Example: a function handling all I/O (read, write, print) chosen by a parameter.

Elements are grouped because they execute at the same time. Example: startup initialization routines bundled together.

Elements are grouped because they follow a specific execution sequence. Example: a function that validates input, then opens a file, then writes a log.

Elements operate on the same data but perform different operations. Example: a module that both validates and formats a customer record.

The output of one element serves as input to the next, forming a pipeline. Example: parse → validate → transform.

Every element contributes to a single, well-defined task. The ideal. Example: calculateShippingCost() does exactly one thing.

Larry Constantine and Edward Yourdon ("Structured Design", 1979). Further developed by Meilir Page-Jones ("The Practical Guide to Structured Systems Design", 1988).

Class-Responsibility-Collaboration Cards

CRC Cards, CRC Card Method, Class-Responsibility-Collaborator Cards

The name of the class or object being modeled — one index card per class

What the class knows (data it holds) and what it does (behavior it provides) — listed on the left side of the card

Other classes this class depends on to fulfill its responsibilities — listed on the right side of the card

Deliberately low-tech: physical cards keep design discussions lightweight, encourage discarding and rethinking, and prevent over-engineering

Team members physically hold cards and walk through scenarios, simulating message passing between objects to validate design

Encourages cross-functional participation; everyone can contribute without needing deep technical background

Start with nouns in the problem description; candidate classes are discovered, not prescribed

Cards are cheap to discard — designs are evolved through multiple rounds of role-playing and critique

Ward Cunningham, Kent Beck ("A Laboratory For Teaching Object-Oriented Thinking", OOPSLA 1989)

Don’t Repeat Yourself

DRY Principle; antonym: WET ("Write Everything Twice" / "We Enjoy Typing")

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." One fact — a business rule, a constant, a schema — lives in exactly one place

DRY targets duplicated knowledge/intent, not coincidental textual similarity. Two code fragments that look alike but change for different reasons are not a DRY violation; collapsing them couples unrelated concerns

Derive rather than restate — generate docs/config/clients from one authoritative definition so a change propagates instead of being copied

Extract a shared abstraction after the third occurrence, not the first (Martin Fowler). Premature de-duplication guesses at an abstraction before the pattern is clear

"Duplication is far cheaper than the wrong abstraction" (Sandi Metz). A bad shared abstraction couples callers and is harder to unwind than the duplication it removed — prefer duplication until the right seam is obvious

Andy Hunt & Dave Thomas, The Pragmatic Programmer (1999)

Patterns of Enterprise Application Architecture according to Martin Fowler

Fowler patterns, PEAA patterns, Enterprise patterns

Transaction Script, Domain Model, Table Module, Service Layer

Table Data Gateway, Row Data Gateway, Active Record, Data Mapper

Unit of Work, Identity Map, Lazy Load

Identity Field, Foreign Key Mapping, Association Table Mapping, Dependent Mapping, Embedded Value, Serialized LOB, Single Table Inheritance, Class Table Inheritance, Concrete Table Inheritance

Metadata Mapping, Query Object, Repository

Model View Controller, Page Controller, Front Controller, Template View, Transform View, Two Step View, Application Controller

Remote Facade, Data Transfer Object

Optimistic Offline Lock, Pessimistic Offline Lock, Coarse-Grained Lock, Implicit Lock

Client Session State, Server Session State, Database Session State

Gateway, Mapper, Layer Supertype, Separated Interface, Registry, Value Object, Money, Special Case, Plugin, Service Stub, Record Set

Martin Fowler ("Patterns of Enterprise Application Architecture", 2002)

GoF Abstract Factory Pattern (Creational)

Kit

GoF Adapter Pattern (Structural)

Wrapper

GoF Bridge Pattern (Structural)

GoF Builder Pattern (Creational)

GoF Chain of Responsibility Pattern (Behavioral)

GoF Command Pattern (Behavioral)

GoF Composite Pattern (Structural)

GoF Decorator Pattern (Structural)

Wrapper

Gang of Four Design Patterns

Design Patterns, Gang of Four Patterns

Abstract Factory, Builder, Factory Method, Prototype, Singleton — object creation mechanisms

Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy — object composition and relationships

Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor — object interaction and responsibility

Shared vocabulary for communicating recurring design problems and proven solutions

Favor object composition for flexibility over rigid class hierarchies

Depend on abstractions rather than concrete implementations

Identify what varies in your design and encapsulate it

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides ("Design Patterns: Elements of Reusable Object-Oriented Software", 1994)

GoF Facade Pattern (Structural)

GoF Factory Method Pattern (Creational)

Virtual Constructor

GoF Flyweight Pattern (Structural)

GoF Interpreter Pattern (Behavioral)

GoF Iterator Pattern (Behavioral)

GoF Mediator Pattern (Behavioral)

GoF Memento Pattern (Behavioral)

GoF Observer Pattern (Behavioral)

Publish-Subscribe, Event-Listener

GoF Prototype Pattern (Creational)

GoF Proxy Pattern (Structural)

GoF Singleton Pattern (Creational)

GoF State Pattern (Behavioral)

Objects for States

GoF Strategy Pattern (Behavioral)

GoF Template Method Pattern (Behavioral)

GoF Visitor Pattern (Behavioral)

General Responsibility Assignment Software Patterns (or Principles)

GRASP Patterns, Responsibility-Driven Design Guidelines

Assign responsibility to the class that has the information needed to fulfill it

Assign responsibility for creating an object to the class that aggregates, contains, or closely uses it

Assign responsibility for handling system events to a non-UI class representing the overall system or a use case

Assign responsibilities to minimize dependencies between classes, increasing reuse and reducing change impact

Assign responsibilities so that classes remain focused, understandable, and manageable

Use polymorphic operations to handle variations in type-based behavior instead of conditionals

Assign a set of responsibilities to an artificial class not representing a domain concept, to achieve low coupling and high cohesion

Assign responsibility to an intermediate object to mediate between other components, reducing direct coupling

Identify points of predicted variation and assign responsibilities to create a stable interface around them

Craig Larman ("Applying UML and Patterns", 3rd ed., 2004)

Integration Operation Segregation Principle

IOSP, Integration-Operation Separation, N+1 Principle

Functions shall either only contain logic or they shall only call other functions — never both.

A function that contains logic but calls no other functions of the same solution. Logic includes transformations (x + 2), control structures (if, for, while), and third-party API calls (Console.WriteLine, httpClient.Send()). Operations are the leaves of the function tree — they have no functional dependencies on other code of the same codebase.

A function that calls other functions (operations or other integrations) but contains no logic itself. Its sole responsibility is composing lower-level functions into a coherent whole. Integrations are the branches of the function tree — they orchestrate, they do not compute.

A function that violates IOSP by mixing both logic and calls to other functions. Hybrids are the primary source of poor testability: the logic cannot be tested in isolation without mocking the called functions, and the calling structure cannot be understood without reading the embedded logic.

A reader encountering an integration can trust it to be a readable summary of the work at that level — pure orchestration without hidden decisions. An operation, conversely, contains only detailed logic — no distracting jumps to other parts of the codebase. This natural enforcement of the Single Level of Abstraction Principle (SLAP) is the key insight: IOSP makes SLAP automatic rather than aspirational.

Code that follows DIP often creates hybrids: a method both contains domain logic and calls abstractions (interfaces) that represent integrations. IOSP argues that these two responsibilities — logic and integration — should be separated into different functions. The result: operations no longer depend on abstractions, integrating functions do the wiring instead. This reduces the need for DIP and Dependency Injection significantly; DIP is retained only for genuine cases of alternative implementations, not for testability.

Operations are trivially unit-testable — they have no functional dependencies that require mocking. Integrations contain no logic, so there is nothing to unit-test; integration tests verify the wiring. This is a categorical improvement over hybrid code, where every test requires mock setup for the called functions.

Following IOSP produces a strict tree structure: integrations form the upper layers (high abstraction, no logic), operations form the leaves (low abstraction, all logic). There are no functional dependencies — only "empty" dependencies from integrations to the functions they call. This makes the data flow visible and the graph acyclic by construction.

Ralf Westphal ("Integration Operation Segregation Principle (IOSP)", 2022 — substack; "IOSP 2.0", 2023; "Radical Object-Orientation #06", 2024), Stefan Lieser ("Three Questions about the IOSP", t2informatik interview, 2025; Clean Code Developer Initiative / CCD Akademie). Both are co-founders of the Clean Code Developer Initiative (2008).

Keep It Simple, Stupid (also: Keep It Super Simple)

KISS, Keep It Simple

Systems work best when kept simple; complexity should be avoided whenever possible

Don’t add complexity, abstraction, or features beyond what the current problem requires

Code that is easy to read and understand is preferred over sophisticated but opaque solutions

Implement the most straightforward approach that satisfies the requirements, then refine if needed

Simpler designs reduce the mental effort required to understand, maintain, and extend a system

Start simple; add complexity only when justified by concrete requirements (pairs with YAGNI)

Kelly Johnson (Lockheed Skunk Works, 1960s), Robert C. Martin ("Clean Code", 2008)

Law of Demeter (LoD)

Principle of Least Knowledge, "Don’t talk to strangers"

A method may call methods on: itself, its parameters, objects it creates, and its direct component objects — but not on objects returned by those calls

Chains like a.getB().getC().doSomething() reach through intermediaries and couple the caller to a deep object graph — the classic LoD violation

Push behaviour to the object that owns the data instead of pulling data out and operating on it externally

LoD limits how much of an object’s internal structure leaks to its collaborators, so internal changes don’t ripple outward

It is a heuristic, not an absolute; fluent builders and some data-pipeline/query DSLs chain deliberately and are reasonable exceptions

Ian Holland & Karl Lieberherr (Northeastern University, Demeter Project, 1987); popularized by "The Pragmatic Programmer" (Hunt & Thomas)

Postel’s Law / The Robustness Principle

"Be conservative in what you send, be liberal in what you accept"

Send strictly conforming output; accept input tolerantly, coping with anything you reasonably can — to maximize interoperability between independently built systems

Emit only well-formed, specification-compliant messages so peers never have to compensate for your sloppiness

Tolerate minor deviations and unknown-but-ignorable fields rather than rejecting otherwise-usable messages — supports forward/backward compatibility

Long-lived network protocols, public APIs, file formats, and event schemas that must evolve while old and new participants coexist

Excessive tolerance accumulates undefined behaviour and security risk (ambiguous parsing, smuggling); contemporary guidance favours strictness plus explicit versioning. Apply with a documented tolerance boundary, not blanket leniency

Jon Postel (RFC 760/761, 1980, in the context of TCP/IP)

Single Level of Abstraction Principle

SLAP, SLA Principle, One Level of Abstraction Per Function

All statements within a single function (or block) should operate at the same level of abstraction. High-level orchestration and low-level mechanics do not belong in the same body.

A reader scanning a function can trust it to answer one question at one resolution. Mixing levels forces the reader to context-switch between "what is this step doing" and "how exactly is it being done" on every line, which is the primary driver of the "I have to read this three times" feeling.

Robert C. Martin formalised SLAP as one of the function-design rules in Clean Code (2008), alongside "Functions should be small", "Do one thing", and "Use descriptive names". SLAP is the organising principle that makes "small functions" readable rather than just fragmented.

Kent Beck (Smalltalk Best Practice Patterns, 1996 — "Composed Method"), Robert C. Martin (Clean Code, 2008).

SOLID Dependency Inversion Principle (DIP)

SOLID Interface Segregation Principle (ISP)

SOLID Liskov Substitution Principle (LSP)

SOLID Open/Closed Principle (OCP)

SOLID Object-Oriented Design Principles

Each class should have one responsibility

Entities should be open for extension, closed for modification

Subtypes must be substitutable for their base types

Clients should not be forced to depend on interfaces they do not use

Depend on abstractions, not concrete implementations

Robert C. Martin ("Uncle Bob")

SOLID Single Responsibility Principle (SRP)

Single Source of Truth

Focuses on establishing trust and authority for data

One canonical, trusted location for each piece of data

All consumers reference the same trusted source

Single source ensures consistent versioning

Other representations are derived from the single source

The source is the definitive version when conflicts arise

The primary data store for critical business information

Applied at the architecture and business process level

You Aren’t Gonna Need It

Only implement functionality when it is actually needed, not when you foresee it might be needed

Anti-pattern of building abstractions for imagined future requirements that may never materialize

Let design emerge through actual needs; evolve architecture as requirements become concrete

Unused code adds maintenance burden, increases complexity, and creates cognitive load for the entire team

Aggressively remove code that no longer serves a current purpose

Core XP practice alongside TDD, refactoring, and continuous integration

Prefer simple, changeable decisions over premature commitments to complex solutions

Ron Jeffries (coined the phrase), Kent Beck ("Extreme Programming Explained", 1999)

Block Element Modifier (BEM) (S)CSS Methodology

Solve CSS specificity wars, naming conflicts, and stylesheet maintainability issues in large codebases

Standalone component that is meaningful on its own (e.g., menu, button, header)

Part of a block with no standalone meaning (e.g., menuitem, buttonicon)

Flag on blocks or elements that changes appearance or behavior (e.g., button—​disabled, menu__item—​active)

block__element—​modifier structure

Blocks are self-contained and reusable

Avoid deep CSS selectors, use flat structure

Clear parent-child relationships through naming

Components can be moved anywhere in the project

Combining multiple BEM entities on a single DOM node

Often paired with component-based file organization

DoD, Done Criteria, Acceptance Criteria (team-level)

A formal, team-wide checklist of quality criteria that every increment must satisfy before it is declared "done"

Concrete, verifiable conditions — e.g., code reviewed, tests passing, documentation updated, no known defects

Makes the meaning of "done" visible and unambiguous to all stakeholders, preventing hidden technical debt

Teams may maintain separate DoD lists for Sprint increments and for releasable product increments

The DoD evolves as the team matures; stricter gates are added over time

Work that does not meet the DoD is not counted as complete; it returns to the Product Backlog

The entire Scrum team (Developers, Product Owner, Scrum Master) owns and respects the DoD

Ken Schwaber & Jeff Sutherland ("The Scrum Guide", 2020); Mike Cohn ("Succeeding with Agile", 2009)

Code is auto-formatted; style debates are eliminated by tooling

Short, lowercase, no underscores; package name is part of the qualified identifier

Return values can be named and used as documentation

Deferred function calls run in LIFO order when the surrounding function returns; used for cleanup (close, unlock)

Lightweight concurrently executing functions; "Don’t communicate by sharing memory; share memory by communicating"

Typed conduits for goroutine communication; first-class synchronization primitive

Implicit satisfaction — a type implements an interface simply by implementing its methods; enables duck typing

Errors are values; idiomatic pattern is if err != nil at each call site; no exceptions

Discard unwanted values from multi-value returns without compiler error

Composition over inheritance; types can embed other types to gain their methods

The Go Authors (https://go.dev/doc/effective_go)

Mental Model according to Naur

Programming is creating a mental model, not just writing code. The real program exists in developers' minds, not in the code.

Code shows what the system does. The theory captures why it is built this way — the reasoning, trade-offs, and domain understanding behind the design.

When original developers leave, the theory is lost. Written code alone cannot reconstruct it. This explains why maintenance by new teams is so difficult.

ADRs document individual architectural decisions. Theory Building goes deeper: document the overarching understanding of why the system is shaped the way it is.

Theory must be shared through collaboration, conversation, and documentation that captures intent, not just structure.

Peter Naur (Turing Award winner, 1978)

"Programming as Theory Building" (1985)

Mikado Graph Method

The clear desired future state of the code after refactoring; the root of the dependency graph and success criterion of the change

Reveal blocking dependencies by attempting the change and noting what breaks

Prefer quick or time-boxed empirical attempts over long upfront analysis

IMPORTANT: After discovering a prerequisite, always revert to the last known working state before addressing it

A directed acyclic graph where goals and prerequisites are nodes and arrows show dependencies

Resolve the leaf nodes (no further prerequisites) first, working back to the root goal

Revert failed experiments immediately; keep or commit only coherent healthy changes

Commit only when the code compiles, tests run, the product is in a good state, and the change makes sense on its own

Ola Ellnestam, Daniel Brolund ("The Mikado Method", 2012)

Compliance Environment, Validated Environment, Regulated Industry Development

Every requirement, design decision, implementation, and test must be linked end-to-end; changes traceable from origin to deployment

Formal proof that a system does what it is intended to do (validation) and is built correctly (verification)

Immutable, timestamped record of who changed what, when, and why; essential for regulatory inspections

Formal process for evaluating, approving, implementing, and documenting any change to a validated system

Specifications (URS, FS, DS), SOPs, test protocols, validation reports, and risk assessments are mandatory deliverables

Effort and rigor proportional to the risk posed by the system (e.g., GAMP 5 categories, FMEA)

Strict segregation of development, testing/qualification, and production environments

Builds, deployments, and test results must be reproducible; version-pinned dependencies and infrastructure-as-code

Legally binding digital sign-off on documents and data (e.g., FDA 21 CFR Part 11)

Third-party components and vendors must be qualified and audited

Semantic Versioning Specification

Append plus sign and identifiers (e.g., 1.0.0+20241111)

Clear rules for version comparison

0.y.z for initial development (API unstable)

Once public API declared, version dependencies matter

Tom Preston-Werner

Site Reliability Engineering (SRE)

"Operations as a software problem", Google SRE

Apply software engineering to operations work instead of manual administration.

Service Level Indicators measure behavior; Objectives set internal targets; Agreements are external commitments.

100% reliability is the wrong target; the allowed unreliability (1 − SLO) is a budget spent on feature velocity and risk.

Reliability is balanced against the cost and speed of change, not maximized blindly.

Reduce repetitive, manual, automatable operational work; cap operational load (~50%) to protect engineering time.

Learn from incidents by analyzing systems and processes rather than assigning blame.

Measure the four golden signals — latency, traffic, errors, saturation.

Automate launches, rollouts, and capacity planning to make change safe and repeatable.

Ben Treynor Sloss (coined the term at Google); Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy ("Site Reliability Engineering", O’Reilly 2016, and "The Site Reliability Workbook")

State-of-the-Art

Focus on the most current, cutting-edge methods and techniques

Reference current research papers, benchmarks, and empirical results

Compare new approaches with existing or previous methods

Emphasize benchmark-leading and best-performing solutions

Provide current, grounded information rather than outdated practices

Support claims with recent studies, benchmarks, and real-world implementations

Consider the specific domain and timeframe for "state-of-the-art"

Spike, Technical Spike, Research Spike

A spike has an explicit, non-negotiable deadline (hours or days, not weeks). When time runs out, the spike ends — even if the answer is incomplete. An unbounded spike has become speculative development.

A spike answers one specific technical question: "Can library X handle our throughput?", "Will the auth provider accept these claims?", "Is Approach A or B faster?". Multiple questions mean multiple spikes.

The code is throwaway. It lives in a branch (or scratch repo), gets studied, and gets deleted. Reusing spike code in production defeats the purpose — spike quality is deliberately rough.

The point of a spike is to reduce uncertainty so a decision can be made. Common outputs: a short writeup, a benchmark number, a "yes/no" answer, an ADR. Never a pull request to main.

Spikes are commonly used when a story cannot be estimated because of unknown unknowns. After the spike, the team can estimate with confidence.

No code review, no test coverage, no polish. The constraint is "learn the answer as fast as possible", which is the opposite of production code.

"Spike: investigate X" is a legitimate work item. Teams should track spikes as first-class, not hide them inside regular stories.

Kent Beck ("Extreme Programming Explained", 1999, 2nd ed. 2004); Ron Jeffries popularized the term in early XP writings

Vertical Slicing, End-to-End Slice

Each increment implements a single small feature end-to-end through every technical layer (UI → logic → persistence → integration) in one piece of work.

The goal of slicing is to keep the system shippable after each increment. "Done" means users can use it, not that one layer is finished.

Horizontal slicing ("finish the DB layer, then the API, then the UI") delays delivery and hides integration problems. Vertical slicing inverts that.

A thin slice is small in scope but complete in depth. Removing any layer breaks the feature; shortening any layer is fine.

Because every slice touches every layer, integration issues surface early and often, not as a terrifying end-of-project merge.

Each slice should produce a user-observable change. "Refactor the user service" is not a vertical slice; "user can change their email" is.

VSA is a structural pattern for organizing code; thin vertical slicing is a delivery technique for organizing work. They are complementary but independent — you can slice thinly with or without VSA.

Alistair Cockburn ("Agile Software Development", 2001); Mike Cohn ("User Stories Applied", 2004)

There Is More Than One Way To Do It

Tim Toady

Acknowledges that problems can be solved in different, equally valid ways

Trust developers to choose the right approach for their context

Languages and tools should support diverse problem-solving styles

The "best" solution depends on constraints, team, and situation

Resist dogma — flexibility over prescription

Different approaches have different trade-offs; none is universally superior

Practical results matter more than theoretical elegance

When working with others, discuss approach rather than assume

Larry Wall (Perl programming language)

Socratic Method (also Socratic Dialogue, Elenchus)

Lead learners to insights through questions rather than direct instruction

Cross-examination technique to expose contradictions in beliefs

"Midwifery of ideas" – helping others give birth to knowledge they already possess

State of productive confusion that motivates deeper inquiry

Progress from clarifying questions to probing assumptions to exploring implications

Structured dialogue to arrive at truth through reasoned argument

Teacher claims ignorance, guides through questions

Make implicit beliefs explicit through systematic questioning

Test ideas for internal coherence and contradictions

Socrates (via Plato’s dialogues, ~400 BCE)

2400+ years of philosophical tradition, foundational to Western philosophy and critical thinking education

Systemic Consulting according to the Heidelberg School

Systemische Beratung, Systemic Therapy and Consulting, Heidelberg Model

"Was all diese Beratungsansätze miteinander verbindet: Es sind Formen der Kommunikation." (Simon, Einführung in die (System-)Theorie der Beratung, 2014) — The consulting process is analyzed through the lens of communication theory.

The consultant takes no side but is partial to all sides simultaneously. "Rollenklärung des Therapeuten sowie Allparteilichkeit und das Prinzip der Neutralität." (Simon/Rech-Simon, Zirkuläres Fragen)

The consultant remains neutral toward persons, toward the problem, and toward change. Not cold distance, but active multiperspectivity.

Instead of linear cause-effect questions ("Why did X happen?"), circular questions explore relationships, differences, and feedback loops: "What would Y say about X’s behavior?" "What needs to happen for the pattern to change?" "Zirkuläres Fragen zielt darauf, die gegenseitige Bedingtheit des Verhaltens von Menschen zu verdeutlichen."

"Die Kontextklärung für Therapeuten ist immer klarer als für Patienten." — Before any intervention, the context must be clarified: who referred, what are the expectations, what is the mandate?

Problems arise from relational patterns, not from individual deficiencies. Changing the pattern changes the problem.

The consultant cannot dictate changes (systems are operatively closed) but can offer perturbations that the system may or may not integrate.

Every behavior that appears dysfunctional is reframed as having a positive function for the system. "Which adaptive function does the status quo serve?"

Before meeting a client, the team generates hypotheses about the system’s dynamics. Hypotheses are treated as provisional and falsifiable.

Clarify referral context → define goals → explore attempted solutions → identify resources → hypothesize patterns → offer intervention.

Fritz B. Simon (Einführung in die (System-)Theorie der Beratung, 2014), Helm Stierlin, Gunthard Weber (Heidelberg School), Paul Watzlawick, Jay Haley, John Weakland (MRI Palo Alto), Mara Selvini Palazzoli (Milan Group)

Solution Fixation, Asking the Wrong Question

The underlying goal the asker actually wants to achieve

The approach the asker has chosen, often based on an incomplete model of X

The asker phrases their request as "How do I do Y?" — X is never stated, only assumed by the asker

Commitment to Y obscures whether Y solves X at all, and may rule out simpler approaches

Conflating "what I want" with "the steps I think will get me there"

Y looks unusual, brittle, or disproportionate to the questioner’s apparent expertise — usually a sign that X is hidden

Ask "What are you actually trying to accomplish?" — surface X, then propose solutions for X (which may or may not include Y)

State X first, then your attempted Y, then the specific blocker — this lets the helper validate the whole chain

Mark Jason Dominus (coined the term in a 2001 post to comp.lang.perl.misc), Eric S. Raymond ("How To Ask Questions The Smart Way", 2001 — "describe the goal, not the step")

Crystallized in Usenet and IRC help culture of the early 2000s; canonical reference at https://xyproblem.info/ and Greg’s Wiki (mywiki.wooledge.org/XyProblem); now part of the standard vocabulary on Stack Overflow, Hacker News, and software help channels.

Diátaxis Documentation Framework according to Daniele Procida

Each type serves a distinct purpose

Different users need different documentation at different times

Each type has specific quality indicators

Framework for organizing any documentation

Daniele Procida

Docs-as-Code Approach according to Ralf D. Müller

AsciiDoc, Markdown

Documentation in Git alongside code

Build pipelines for documentation

Generate multiple output formats from one source

PlantUML, Mermaid, Graphviz, Kroki

Updated with every commit

Use same tools and workflows as for code

Pull requests for documentation changes

Includes and composition

Ralf D. Müller (docToolchain creator)

Getting Things Done (GTD)

GTD, GTD by David Allen, GTD Methodology

Collect everything that has your attention — tasks, ideas, commitments — into trusted external "inboxes" so nothing is held in your head

Process each captured item: Is it actionable? If yes, define the next physical action. If no, trash it, incubate it, or file it as reference

Place clarified items into the right lists — Next Actions, Projects, Waiting For, Someday/Maybe, Calendar — so they are retrievable at the right moment

Review your system regularly (Weekly Review) to keep it current, complete, and trusted

Choose which actions to take based on context, time available, energy, and priority

If an action takes less than two minutes, do it immediately rather than deferring it

Any desired outcome requiring more than one action step is a "project" tracked on a dedicated list with at least one next action

Next actions are tagged by context (e.g., @computer, @phone, @errands) to batch work efficiently

All commitments are stored externally so the mind is free to focus on doing rather than remembering

David Allen ("Getting Things Done: The Art of Stress-Free Productivity")

Hemingway Bridge

Stop Mid-Sentence Technique, Re-entry Point Strategy

End each work session deliberately before reaching a natural stopping point, while you still know exactly what comes next — preserving momentum for the next session

Leave a clear "bridge" to the next session: an unfinished sentence, a comment, a TODO note, or a short summary of the next steps so you can re-engage immediately without warm-up

Avoid depleting all creative or cognitive energy in one session; stopping when energy is still high makes it easier to start again

By never fully stopping, you eliminate the paralysing "blank page" moment at the start of the next session

The psychological state of "knowing what comes next" is transferred across time boundaries, keeping flow intact across interruptions

A brief note written at the end of a session ("next: implement X, blocked by Y") acts as an explicit Hemingway Bridge — a ready-made launchpad

Ernest Hemingway (interviewed in George Plimpton (ed.), "The Paris Review Interviews"; practical elaboration by Steven Pressfield and others in the context of creative work)

P.A.R.A. Method (Projects, Areas, Resources, Archive)

PARA Framework, Second Brain Organization System

Short-term efforts with a specific goal and deadline (e.g., "Launch website", "Write article")

Long-term responsibilities with a standard to maintain over time (e.g., "Health", "Finances", "Team Management")

Topics of ongoing interest or future relevance without a current action (e.g., "Machine Learning", "Design Patterns")

Inactive items from the other three categories — completed projects, dropped areas, or obsolete resources

Items are organized by how actionable they are, not by topic or type

Applicable to any note-taking or file management system (Notion, Obsidian, Roam Research, plain folders)

Each piece of information belongs in exactly one of the four categories

Tiago Forte ("Building a Second Brain")

todo.txt-flavoured Markdown Task Lists

Enhanced Markdown Tasks, Markdown with todo.txt conventions

Standard GitHub-flavoured markdown syntax (- [ ] uncompleted, - [x] completed)

Uses todo.txt priority notation (A), (B), © where (A) is highest priority

Prefixed with + to group related tasks (e.g., +website, +semantic-anchors)

Prefixed with @ to indicate location/tool/context (e.g., @computer, @home, @research)

Structured data pairs like due:YYYY-MM-DD, priority:high, or custom fields

Creation dates and completion dates in ISO format (YYYY-MM-DD)

Plain text format that remains readable without special tools

Can be processed by both markdown renderers and todo.txt tools

Easy to grep/search by tags, priorities, or metadata

Combines GitHub-flavoured Markdown task lists with Gina Trapani’s todo.txt format

Luhmann’s Sociological System Theory (Luhmannsche Systemtheorie)

Theory of Autopoietic Social Systems, Functional-Structural Systems Theory

A system defines itself by drawing a distinction (Differenz) between itself and its environment. "Es gibt kein System ohne Umwelt. Hier ist das System, dort die Umwelt. Wer das sagt, unterscheidet zwischen diesen beiden." (Luhmann, Einführung in die Systemtheorie, Kap. II)

Systems reproduce themselves through their own operations. Social systems operate through communication, psychic systems through thought. No operation crosses the boundary. "Selbstreferentielle Geschlossenheit ist nur in einer Umwelt, ist nur unter ökologischen Bedingungen möglich."

Systems produce and reproduce their own elements. A system exists as long as operations connect to operations. "Ein System erhält sich dadurch, dass Operationen aneinander anschließen."

Systems cannot directly interact, but they can build expectation structures that make them sensitive to specific irritations from their environment. Language couples psychic and social systems.

The foundational paradox of social interaction: "I will do what you want if you do what I want" — resolved only through the emergence of social systems. "Das gesamte Soziale kann als Antwort auf das Problem der doppelten Kontingenz gesehen werden." (Soziale Systeme, Kap. IV)

Systems observe themselves by distinguishing self-reference from external reference (Fremdreferenz). "Beobachten heißt: unterscheiden (→ differenzieren)."

Social systems consist of communication, not of people. Communication is the synthesis of information, utterance, and understanding.

Systems reduce environmental complexity through selection. "Sinn" (meaning) is the medium through which psychic and social systems process complexity.

Modern society differentiates into function systems (economy, law, politics, science, religion) each with their own binary code.

Niklas Luhmann (Soziale Systeme, 1984; Einführung in die Systemtheorie, Vorlesung 1991/92, hg. v. Dirk Baecker), Humberto Maturana (autopoiesis, biological roots)

Simon’s Introduction to System Theory and Constructivism

Simon’s Systemic Epistemology, Clinical Epistemology

"Systemtheorie beschäftigt sich mit der 'Welt der Objekte'; aber sie isoliert sie nicht aus ihren realen Zusammenhängen, sondern setzt sie in Beziehung zueinander." Systemisches Denken ist systemtheoretisches Erklären — nicht nur Beschreiben. (Simon, Einführung in Systemtheorie und Konstruktivismus, Vorbemerkung)

"Systeme sind aus mehreren Teilen zusammengesetzte Einheiten, deren Eigenschaften emergent, d.h. nicht durch die schlichte Addition der Eigenschaften ihrer Teile herstellbar waren." (Kap. 1)

Trivial machines are predictable (same input → same output). Non-trivial machines depend on internal state — they are history-dependent and not fully predictable. Social systems are non-trivial machines. (Kap. 3.1)

The observer is always part of the observed system. "Die Kybernetik der Kybernetik — der Beobachter wird in die Beobachtung einbezogen." (Kap. 3.2)

"Wahrheit vs. Viabilität — Die 'Passung' zwischen Landschaft und Landkarte." Knowledge is not "true" in an absolute sense, but viable if it enables successful operation in a given environment. (Kap. 4.5)

(Gregory Bateson) Information is not transmitted but created by the receiver. "Unterschiede, die Unterschiede machen." The Sender-Receiver model is replaced by circular causality. (Kap. 4.1)

Every observation draws a distinction and names one side. The other side remains unmarked. (Kap. 4.3, following George Spencer-Brown)

"Systeme sind operativ geschlossen und können nur nach ihrer eigenen Logik operieren." (Kap. 3.4)

"Systeme können nicht instruiert, nur irritiert (perturbiert) werden." — A crucial principle for any intervention design. (Kap. 3.5)

Systems shape each other’s environments over time, leading to coordinated structural drift without direct causality. (Kap. 5.1)

Every communication (in Luhmann’s sense) operates simultaneously in three dimensions: social (who), factual (what), temporal (when). (Kap. 6.4, following Luhmann)

Fritz B. Simon (Einführung in Systemtheorie und Konstruktivismus, 2006, 8. Aufl. 2017), Humberto Maturana (autopoiesis), Gregory Bateson (cybernetics), Heinz von Foerster (constructivism), Ernst von Glasersfeld (radical constructivism)

Chain of Thought Prompting

Explicitly show intermediate reasoning steps before reaching a conclusion

Make the thought process visible, not just the final answer

Break complex problems into smaller, manageable steps

Exposing reasoning allows detection of logical errors mid-process

Handle multi-step problems that cannot be solved in one jump

Simple prompt like "Let’s think step by step" to trigger CoT behavior

Provide examples with reasoning chains to guide the model

Generate multiple reasoning paths and select most consistent answer

Wei et al. (Google Research, 2022), "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models"

Breakthrough in LLM prompting research, significantly improved performance on reasoning tasks (math, logic, common sense)

Benjamin Franklin Analysis, Moral Algebra, Pros-and-Cons Sheet

The full Janis & Mann form has four categories of consequence for each alternative — utilitarian gains/losses for self, utilitarian gains/losses for significant others, self-approval/disapproval, and approval/disapproval from others. Stretches "pros and cons" beyond instrumental outcomes into identity and social cost.

The everyday "pros vs cons" list popularised by Benjamin Franklin (1772 letter to Joseph Priestley). Strictly a degenerate case of the four-cell matrix — useful for quick decisions, lossy for complex ones.

Each entry gets a numeric weight reflecting its importance. The decision is not a vote count — the discipline is to make trade-offs explicit, not to mechanise the choice.

The artifact’s primary purpose is not arithmetic but surfacing concerns the decider has not yet articulated. Listing the cons of a tempting option, or the pros of the rejected one, breaks the "all pros, no cons" framing that drives impulsive decisions.

Janis & Mann’s parent theory; high-stakes decisions produce stress that distorts judgment. The balance sheet is one of several debiasing techniques alongside vigilant information search and contingency planning.

In the Prochaska–DiClemente Stages of Change model and Miller & Rollnick’s Motivational Interviewing, the balance sheet is used to elicit change-talk: the client says the cons of staying the same and the pros of changing — moving them through ambivalence rather than persuading them.

The model is deliberative, not intuitive. It works poorly under time pressure and for decisions dominated by uncertainty (where Pugh Matrix or scenario-based methods fit better). It also doesn’t surface options that aren’t on the list — separate from the option-generation step.

Irving Janis & Leon Mann ("Decision Making: A Psychological Analysis of Conflict, Choice, and Commitment", 1977 — the formal four-cell model). Benjamin Franklin (1772 letter, "moral algebra" — the informal pros/cons ancestor). William R. Miller & Stephen Rollnick ("Motivational Interviewing", 1991) for the clinical adaptation.

Franklin’s pros/cons letter is one of the earliest documented decision-aid techniques in the Western tradition. Janis & Mann turned it into a research instrument in the 1970s; the simplified two-column form has spread through self-help, coaching, and Motivational Interviewing into mainstream use. Now a staple of decision coaching, financial advisory, and health-behaviour-change interventions.

Devil’s Advocate (Latin: Advocatus Diaboli)

Present opposing viewpoints even if not personally held

Question premises and surface hidden assumptions

Identify weaknesses before they become problems

Present the strongest version of the opposing argument, not a strawman

Separate idea evaluation from ego or political concerns

Imagine failure scenarios to prevent them

Thesis + Antithesis → Synthesis

Surface potential problems proactively

Catholic Church canonization process (Promotor Fidei role, formalized 1587), secularized in critical thinking and decision-making

400+ years as formalized practice in the Church, adopted widely in law, philosophy, business strategy, and red teaming

Double Diamond Design Process Model

4Ds Model, Design Council Double Diamond

Discover → Define → Develop → Deliver. Each diamond is one divergent-convergent cycle. The first diamond explores and frames the problem; the second diamond explores and ships the solution.

Broad research — interviews, observation, immersion, data analysis. Goal: widen the understanding of what’s actually going on, not jump to causes.

Synthesize findings into a sharp problem statement. The famous slogan: "Are we solving the right problem?" — the diamond ends with a problem worth solving, not a list of features.

Generate many candidate solutions — sketches, prototypes, co-design workshops. Diverge widely before narrowing; resist solution fixation.

Test, refine, ship. The chosen concept is iterated until it’s production-ready; failed candidates are explicitly killed rather than left lingering.

The canonical summary. The first diamond addresses "right thing" (problem worth solving); the second addresses "thing right" (solution that works).

A hard discipline at every phase. Premature convergence — picking the obvious problem or obvious solution — is the failure mode the model is designed to prevent.

The diamonds are not strictly linear. Learnings in Develop frequently send the team back to Discover or Define. The 2019 Framework for Innovation update made this explicit.

The Design Council pairs the four phases with four principles (Put people first, Communicate visually and inclusively, Collaborate and co-create, Iterate, iterate, iterate) — the diamonds without the mindset is just process theater.

UK Design Council (originally published 2005; expanded as Framework for Innovation in 2019). Built on the divergent-convergent tradition of J.P. Guilford (1956) and Béla H. Bánáthy.

Developed by the Design Council in 2005 after research into how leading design organizations actually worked. The 2019 update reframed it as a system-level innovation framework, adding the principles, key roles, and explicit iteration arrows. Adopted broadly in UX, service design, government innovation (UK GDS, NHS, Danish Mindlab), and design education.

Feynman Technique (also Feynman Learning Method)

Teach the concept in simple language as if to a beginner (traditionally "explain to a 12-year-old")

When you struggle to explain, you’ve found gaps in your understanding

Go back and re-learn the parts you couldn’t explain clearly

Refine explanation using plain language and concrete examples

Repeat the cycle until you can explain clearly and simply

Inability to avoid jargon signals lack of true understanding

Transform passive reading into active teaching

Become aware of what you don’t know

Richard Feynman (Nobel Prize-winning physicist, 1965), famous for making complex physics accessible

Feynman was renowned for his teaching ability and his belief that deep understanding meant being able to explain simply. The "technique" is a formalization of his learning approach.

First Principles Thinking

Reasoning from First Principles, Reasoning from Fundamentals

Break a problem down to the basic truths that cannot be deduced from anything more fundamental, then reason upward from those

Contrast with reasoning by analogy ("we do it this way because that’s how it’s done") — first principles rebuild the answer from the ground up

Each "requirement" or "constraint" is interrogated: is it a law of nature, or merely convention/legacy that can be discarded?

After identifying the irreducible elements, recombine them into a solution unconstrained by how the problem was solved before

Powerful but expensive — reserve it for high-stakes or stuck problems; reasoning by analogy is fine for routine decisions

Rooted in Aristotle (the "first cause"/archē); sharpened by René Descartes' methodical doubt; popularized in modern engineering discourse (e.g. Elon Musk’s cost-of-batteries example)

Five Whys Root Cause Analysis

Ask "Why?" repeatedly (typically ~5 times) to drill down to root causes

Distinguish between surface symptoms and underlying causes

Each answer becomes the subject of the next "Why?" question

Continue until you reach a cause that can be acted upon

No complex tools or statistical analysis required

Collaborative exploration of causal relationships

Focus on process failures, not individual fault

Once root cause is found, design interventions

Taiichi Ohno (Toyota Production System, 1950s)

Core tool in Lean Manufacturing and Toyota Production System (TPS), foundational to continuous improvement (Kaizen)

Luhmann’s Sociological System Theory (Luhmannsche Systemtheorie)

Theory of Autopoietic Social Systems, Functional-Structural Systems Theory

A system defines itself by drawing a distinction (Differenz) between itself and its environment. "Es gibt kein System ohne Umwelt. Hier ist das System, dort die Umwelt. Wer das sagt, unterscheidet zwischen diesen beiden." (Luhmann, Einführung in die Systemtheorie, Kap. II)

Systems reproduce themselves through their own operations. Social systems operate through communication, psychic systems through thought. No operation crosses the boundary. "Selbstreferentielle Geschlossenheit ist nur in einer Umwelt, ist nur unter ökologischen Bedingungen möglich."

Systems produce and reproduce their own elements. A system exists as long as operations connect to operations. "Ein System erhält sich dadurch, dass Operationen aneinander anschließen."

Systems cannot directly interact, but they can build expectation structures that make them sensitive to specific irritations from their environment. Language couples psychic and social systems.

The foundational paradox of social interaction: "I will do what you want if you do what I want" — resolved only through the emergence of social systems. "Das gesamte Soziale kann als Antwort auf das Problem der doppelten Kontingenz gesehen werden." (Soziale Systeme, Kap. IV)

Systems observe themselves by distinguishing self-reference from external reference (Fremdreferenz). "Beobachten heißt: unterscheiden (→ differenzieren)."

Social systems consist of communication, not of people. Communication is the synthesis of information, utterance, and understanding.

Systems reduce environmental complexity through selection. "Sinn" (meaning) is the medium through which psychic and social systems process complexity.

Modern society differentiates into function systems (economy, law, politics, science, religion) each with their own binary code.

Niklas Luhmann (Soziale Systeme, 1984; Einführung in die Systemtheorie, Vorlesung 1991/92, hg. v. Dirk Baecker), Humberto Maturana (autopoiesis, biological roots)

Morphological Analysis / Morphological Box (German: Morphologischer Kasten)

Break complex problem into independent parameters/dimensions

Identify possible values/options for each parameter

Organize parameters and variants in table/box form

Systematically examine combinations of variants

Eliminate infeasible or contradictory combinations

Find non-obvious solutions through systematic recombination

Ensure all possibilities are considered

Systematic approach to innovation and ideation

Fritz Zwicky (1940s-1960s, California Institute of Technology)

Developed for aerospace engineering problems (jet engines, spacecraft propulsion), now widely applied in product development, system design, and innovation management.

Occam’s Razor (also spelled Ockham’s Razor)

Law of Parsimony, Principle of Parsimony, Lex Parsimoniae, "Entities should not be multiplied beyond necessity"

Among competing hypotheses that explain the same observations equally well, prefer the one that requires the fewest assumptions. The razor shaves off unnecessary entities, causes, or mechanisms.

The razor is a prior, not a verdict. Reality is frequently non-parsimonious, and "simpler" is relative to a chosen ontology. Einstein’s corollary — "as simple as possible, but no simpler" — warns against under-fitting. Pair Occam with evidence, not as a substitute for it.

William of Ockham (c. 1287–1347, Summa Logicae, Quodlibetal Questions); the principle predates Ockham in Aristotle and Scotus but carries his name due to his repeated methodological use of it. Modernised by Bertrand Russell and formalised as minimum-description-length / Bayesian simplicity priors in 20th-century philosophy of science.

Simon’s Introduction to System Theory and Constructivism

Simon’s Systemic Epistemology, Clinical Epistemology

"Systemtheorie beschäftigt sich mit der 'Welt der Objekte'; aber sie isoliert sie nicht aus ihren realen Zusammenhängen, sondern setzt sie in Beziehung zueinander." Systemisches Denken ist systemtheoretisches Erklären — nicht nur Beschreiben. (Simon, Einführung in Systemtheorie und Konstruktivismus, Vorbemerkung)

"Systeme sind aus mehreren Teilen zusammengesetzte Einheiten, deren Eigenschaften emergent, d.h. nicht durch die schlichte Addition der Eigenschaften ihrer Teile herstellbar waren." (Kap. 1)

Trivial machines are predictable (same input → same output). Non-trivial machines depend on internal state — they are history-dependent and not fully predictable. Social systems are non-trivial machines. (Kap. 3.1)

The observer is always part of the observed system. "Die Kybernetik der Kybernetik — der Beobachter wird in die Beobachtung einbezogen." (Kap. 3.2)

"Wahrheit vs. Viabilität — Die 'Passung' zwischen Landschaft und Landkarte." Knowledge is not "true" in an absolute sense, but viable if it enables successful operation in a given environment. (Kap. 4.5)

(Gregory Bateson) Information is not transmitted but created by the receiver. "Unterschiede, die Unterschiede machen." The Sender-Receiver model is replaced by circular causality. (Kap. 4.1)

Every observation draws a distinction and names one side. The other side remains unmarked. (Kap. 4.3, following George Spencer-Brown)

"Systeme sind operativ geschlossen und können nur nach ihrer eigenen Logik operieren." (Kap. 3.4)

"Systeme können nicht instruiert, nur irritiert (perturbiert) werden." — A crucial principle for any intervention design. (Kap. 3.5)

Systems shape each other’s environments over time, leading to coordinated structural drift without direct causality. (Kap. 5.1)

Every communication (in Luhmann’s sense) operates simultaneously in three dimensions: social (who), factual (what), temporal (when). (Kap. 6.4, following Luhmann)

Fritz B. Simon (Einführung in Systemtheorie und Konstruktivismus, 2006, 8. Aufl. 2017), Humberto Maturana (autopoiesis), Gregory Bateson (cybernetics), Heinz von Foerster (constructivism), Ernst von Glasersfeld (radical constructivism)

Systemic Consulting according to the Heidelberg School

Systemische Beratung, Systemic Therapy and Consulting, Heidelberg Model

"Was all diese Beratungsansätze miteinander verbindet: Es sind Formen der Kommunikation." (Simon, Einführung in die (System-)Theorie der Beratung, 2014) — The consulting process is analyzed through the lens of communication theory.

The consultant takes no side but is partial to all sides simultaneously. "Rollenklärung des Therapeuten sowie Allparteilichkeit und das Prinzip der Neutralität." (Simon/Rech-Simon, Zirkuläres Fragen)

The consultant remains neutral toward persons, toward the problem, and toward change. Not cold distance, but active multiperspectivity.

Instead of linear cause-effect questions ("Why did X happen?"), circular questions explore relationships, differences, and feedback loops: "What would Y say about X’s behavior?" "What needs to happen for the pattern to change?" "Zirkuläres Fragen zielt darauf, die gegenseitige Bedingtheit des Verhaltens von Menschen zu verdeutlichen."

"Die Kontextklärung für Therapeuten ist immer klarer als für Patienten." — Before any intervention, the context must be clarified: who referred, what are the expectations, what is the mandate?

Problems arise from relational patterns, not from individual deficiencies. Changing the pattern changes the problem.

The consultant cannot dictate changes (systems are operatively closed) but can offer perturbations that the system may or may not integrate.

Every behavior that appears dysfunctional is reframed as having a positive function for the system. "Which adaptive function does the status quo serve?"

Before meeting a client, the team generates hypotheses about the system’s dynamics. Hypotheses are treated as provisional and falsifiable.

Clarify referral context → define goals → explore attempted solutions → identify resources → hypothesize patterns → offer intervention.

Fritz B. Simon (Einführung in die (System-)Theorie der Beratung, 2014), Helm Stierlin, Gunthard Weber (Heidelberg School), Paul Watzlawick, Jay Haley, John Weakland (MRI Palo Alto), Mara Selvini Palazzoli (Milan Group)

What Would Chuck Norris Do?

WWCND, Chuck Norris framing, "What would Chuck do?"

A disposition, not a methodology: commit to the most direct, effective solution; refuse hedging; refuse premature optimisation; refuse ceremony that does not buy risk reduction. The activation is driven by the Chuck Norris facts meme corpus (circa 2005–) and its well-established software subcorpus ("Chuck Norris doesn’t write unit tests — the code is too afraid to fail"), both of which are densely present in modern LLM training data.

WWCND is a Tier 3, qualified anchor. It is not self-standing in the way that GoF Patterns or DDD are. Used bare it produces humour with signal; used with a short qualifier — "WWCND: commit to the most direct solution" — it behaves reliably across scenarios. It activates one disposition, not an interconnected body of engineering knowledge.

The Chuck Norris humour format is built on absurd competence — the subject overcomes constraints that would stop anyone else. Applied to software problems, that frame consistently steers the model toward action-biased, commitment-first answers and away from multi-option hedging. Cross-model testing (see below) shows the activation is stable enough to treat as an anchor rather than a stylistic quirk.

Validated by Cornelius Schumacher (Protocol v3, April 2026) across Claude Sonnet 4.6, Gemini 3.1 Pro, and GPT-5.3 Codex: 19 prompts × N=2 = 114 manually scored responses. Key results: WWCND exceeds a "be direct, don’t hedge" control condition on engagement (12/12 scenario-model pairs) and insight quality (12/12); three independent models converged on the same primary recommendation in all four test scenarios (12/12 agreement); five architectural patterns (Strangler Fig, modular monolith / packwerk, team expertise, regression-for-specific-bug, CI gate) appeared unprompted across all three models. Full report: https://github.com/cornelius/what-would-chuck-norris-do

GPT-5.3 Codex activates the decisiveness signal but not the character voice — it treats all persona anchors with a uniform pragmatic style. Expect diminished distinctiveness on Codex-class models. The recommendation content is consistent; the framing is muted.

Ian Spector, The Truth About Chuck Norris (Gotham Books, 2007); Ian Spector and Chuck Norris, The Official Chuck Norris Fact Book (Thomas Nelson, 2009) — co-authored with Norris. Empirical catalog validation: Cornelius Schumacher, Protocol v3 (April 2026).

Solution Fixation, Asking the Wrong Question

The underlying goal the asker actually wants to achieve

The approach the asker has chosen, often based on an incomplete model of X

The asker phrases their request as "How do I do Y?" — X is never stated, only assumed by the asker

Commitment to Y obscures whether Y solves X at all, and may rule out simpler approaches

Conflating "what I want" with "the steps I think will get me there"

Y looks unusual, brittle, or disproportionate to the questioner’s apparent expertise — usually a sign that X is hidden

Ask "What are you actually trying to accomplish?" — surface X, then propose solutions for X (which may or may not include Y)

State X first, then your attempted Y, then the specific blocker — this lets the helper validate the whole chain

Mark Jason Dominus (coined the term in a 2001 post to comp.lang.perl.misc), Eric S. Raymond ("How To Ask Questions The Smart Way", 2001 — "describe the goal, not the step")

Crystallized in Usenet and IRC help culture of the early 2000s; canonical reference at https://xyproblem.info/ and Greg’s Wiki (mywiki.wooledge.org/XyProblem); now part of the standard vocabulary on Stack Overflow, Hacker News, and software help channels.

Cockburn Use Cases (Writing Effective Use Cases)

Fully Dressed Use Cases, Goal-Level Use Cases, Cockburn Format

A structured textual template for describing system behavior from the actor’s perspective. Each use case includes: Primary Actor, Stakeholders & Interests, Preconditions, Trigger, Main Success Scenario (numbered steps), Extensions (alternative/failure paths with step references), Postconditions (success guarantee and minimal guarantee), and Technology & Data Variations.

Three abstraction levels that organise use cases into a hierarchy:

Defines the system boundary — what is inside the "design scope" and what is an external actor. Cockburn uses icons (a box for the system, a person for actors) to make the boundary visual. Getting scope right prevents use cases from being either too vague (organisational scope) or too detailed (component scope).

The discovery technique: list every actor and every goal they have against the system. This produces a candidate use case list before writing any prose. The goal level test: "Does the actor go home happy if this goal is achieved?" filters out subfunctions masquerading as user goals.

Cockburn’s format is deliberately prose-based and notation-agnostic. It does not mandate Activity Diagrams, Gherkin, EARS, or any formal syntax. Those are complementary representations that can be layered on top — Activity Diagrams for visual flow, Gherkin for executable acceptance criteria, EARS for structured requirement statements.

Alistair Cockburn (Writing Effective Use Cases, Addison-Wesley, 2001). The book remains the canonical reference; Cockburn also contributed to the Agile Manifesto and Crystal methodologies.

Double Diamond Design Process Model

4Ds Model, Design Council Double Diamond

Discover → Define → Develop → Deliver. Each diamond is one divergent-convergent cycle. The first diamond explores and frames the problem; the second diamond explores and ships the solution.

Broad research — interviews, observation, immersion, data analysis. Goal: widen the understanding of what’s actually going on, not jump to causes.

Synthesize findings into a sharp problem statement. The famous slogan: "Are we solving the right problem?" — the diamond ends with a problem worth solving, not a list of features.

Generate many candidate solutions — sketches, prototypes, co-design workshops. Diverge widely before narrowing; resist solution fixation.

Test, refine, ship. The chosen concept is iterated until it’s production-ready; failed candidates are explicitly killed rather than left lingering.

The canonical summary. The first diamond addresses "right thing" (problem worth solving); the second addresses "thing right" (solution that works).

A hard discipline at every phase. Premature convergence — picking the obvious problem or obvious solution — is the failure mode the model is designed to prevent.

The diamonds are not strictly linear. Learnings in Develop frequently send the team back to Discover or Define. The 2019 Framework for Innovation update made this explicit.

The Design Council pairs the four phases with four principles (Put people first, Communicate visually and inclusively, Collaborate and co-create, Iterate, iterate, iterate) — the diamonds without the mindset is just process theater.

UK Design Council (originally published 2005; expanded as Framework for Innovation in 2019). Built on the divergent-convergent tradition of J.P. Guilford (1956) and Béla H. Bánáthy.

Developed by the Design Council in 2005 after research into how leading design organizations actually worked. The 2019 update reframed it as a system-level innovation framework, adding the principles, key roles, and explicit iteration arrows. Adopted broadly in UX, service design, government innovation (UK GDS, NHS, Danish Mindlab), and design education.

Easy Approach to Requirements Syntax

"The <system> shall <requirement>"

"WHEN <trigger> the <system> shall <requirement>"

"IF <condition>, THEN the <system> shall <requirement>"

"WHILE <state>, the <system> shall <requirement>"

"WHERE <feature is included>, the <system> shall <requirement>"

Consistent templates for clarity

Requirements written to be verifiable

Alistair Mavin (Rolls-Royce)

Event Storming

EventStorming (Brandolini)

Model the domain as past-tense domain events (orange stickies) placed left-to-right on a wide wall, reconstructing how the business actually unfolds over time

A fixed sticky vocabulary — orange = Domain Event, blue = Command, yellow = Aggregate, lilac = Policy (reactive "whenever… then…"), green = Read Model, pink = External System, red = Hotspot (conflict, question, assumption)

Big Picture (explore the whole domain with all stakeholders), Process Modeling (zoom into one flow: command → event → policy → command), Design Level (aggregates, commands and events detailed enough to drive implementation)

Events that mark phase transitions or boundaries — strong candidates for bounded context seams

Make conflicts, unknowns and assumptions explicit on the wall instead of glossing over them — they become the agenda

Everyone adds events in parallel first (diverge), then the group orders and de-duplicates them into a coherent line (converge)

Alberto Brandolini (first run 2012, "Introducing EventStorming" blog post 2013; Leanpub book, continuously updated)

INVEST Criteria for User Stories

INVEST Checklist, INVEST Mnemonic

Stories should be self-contained and deliverable in any order; avoid dependencies between stories that force a fixed implementation sequence

Stories are not contracts; the details are open to discussion between team and stakeholders until they enter a sprint

Every story must deliver clear value to the user or business; stories that only serve technical needs should be wrapped in user-visible value

The team must be able to estimate the story’s size; if they cannot, the story is too large, too vague, or requires a spike

Stories should be small enough to complete within a single sprint; large epics must be broken down before entering a sprint