blogs
Kinds of software "things"
Axes that cut kinds (not instances):
- Force — does it describe what is, prescribe what to do, or warn what to avoid?
- Locus — where it primarily lives: code, system/boundary, org, or mind/process
- Ontic role — reusable form, measurable property, truth-claim, symptom, or thinking stance
Scale (local vs system-wide) is degree, not kind. Design pattern and architectural pattern are the same kind at different grain.
Refined kinds
1. Reusable form
Thing-in-itself: A named, contextual solution structure for a recurring design problem. Usual names: design pattern, architectural pattern, idiom, pattern language entry. Force: prescribe. Locus: code → system. Role: form. Examples: Singleton, Factory, MVC, microservices, RAII, goroutine-per-request.
2. Empirical claim
Thing-in-itself: An observed regularity about software, teams, or users over time — not an instruction. Usual names: eponymous law, heuristic, rule of thumb, empirical observation. Force: describe. Locus: org / socio-technical. Role: claim. Examples: Hyrum's Law, Conway's Law, Brooks' Law, "second-order effects."
3. Failure form (anti-pattern)
Thing-in-itself: A recurring solution-shaped move that reliably produces bad outcomes in a known context. Usual names: anti-pattern, antipattern. Force: warn (with a story of how you get there). Locus: code → system. Role: form (negative). Examples: God Object, Spaghetti Code, Golden Hammer, Big Ball of Mud.
4. Symptom (smell)
Thing-in-itself: A surface cue that often signals a deeper problem; not itself the diagnosis. Usual names: code smell, design smell. Force: warn (weak). Locus: code / design surface. Role: symptom. Examples: Long Method, Feature Envy, Shotgun Surgery. ≠ anti-pattern: smell is the hint; anti-pattern is the named bad journey.
5. System property
Thing-in-itself: A relational quality of structure or behavior you can argue about as more/less. Usual names: coupling, cohesion, modularity, encapsulation, latency, throughput, complexity. Force: describe (sometimes with preferred direction). Locus: system. Role: property. Examples: tight coupling, high cohesion, cyclomatic complexity.
6. Boundary phenomenon
Thing-in-itself: What happens at a seam — hide, leak, contract, or dependency across an interface. Usual names: abstraction, leaky abstraction, API contract, de facto contract, impedance mismatch. Force: describe. Locus: boundary. Role: claim about seams (or consequence of them). Examples: Law of Leaky Abstractions, Hyrum's "observable behavior = contract."
7. Design maxim
Thing-in-itself: A short ought-claim that steers choices; thinner than a full methodology. Usual names: principle, maxim, guideline, best practice (when normative). Force: prescribe. Locus: mind → code. Role: claim (normative). Examples: KISS, YAGNI, DRY, SOLID pieces, "prefer composition over inheritance." ≠ empirical claim: maxim says what you should; law/heuristic says what tends to happen.
8. Stance / paradigm / method
Thing-in-itself: A coherent lens for how to think, write, or organize work. Usual names: programming paradigm, design philosophy, development methodology, process. Force: prescribe (as worldview). Locus: mind / org. Role: stance. Examples: FP, OOP, Agile, Waterfall, DevOps, TDD-as-discipline. ≠ maxim: stance is a whole kit; maxim is a one-liner inside or across stances.
9. Deferred-cost metaphor
Thing-in-itself: Accounting language for choosing a cheaper-now path that accrues interest later. Usual names: technical debt, design debt, architecture debt. Force: warn / explain trade. Locus: org + system. Role: metaphor for liability. ≠ smell / anti-pattern: debt names the economic frame; smells/anti-patterns name the structure.
10. Deceptive interaction pattern
Thing-in-itself: UI/UX deliberately shaped to trick or trap the user. Usual names: dark pattern, deceptive design. Force: warn (ethical). Locus: product / UX. Role: form (manipulative). ≠ code anti-pattern: targets humans' decisions, not maintainability of structure.
Quick discriminators
| If you mean… | Kind |
|---|---|
| "Reuse this shape for problem X" | Reusable form |
| "This keeps happening in the wild" | Empirical claim |
| "This path looks good then bites" | Failure form |
| "This surface cue suggests rot" | Symptom |
| "How bound/independent are these?" | System property |
| "What crosses / leaks at the seam?" | Boundary phenomenon |
| "You ought to prefer Y" | Design maxim |
| "Think/work in this whole style" | Stance / paradigm / method |
| "We borrowed against the future" | Deferred-cost metaphor |
| "The UI is designed to trick" | Deceptive interaction |
Collection schema (when seeding instances)
- name
- kind (one of the ten above)
- force (describe / prescribe / warn)
- locus (code / boundary / system / org / mind)
- originator (optional)
- one-line gist
- canonical example
Lookup
- Software Principles
- The Nature of Software
- squishy-computer
- Making Software
- difference-between (heuristic vs best-practice, etc.)