WORTH: A Framework for Context-Driven Technology Decisions

A pragmatic approach to cutting through dogma and making engineering choices that deliver real value

Version: 1.1
Author: Jean Luck Sossmeier
Date: October 2025 (updated July 2026)
Repository: github.com/jeansossmeier/worth

Important boundaries: WORTH is a decision aid, not legal, financial, security, compliance, or procurement advice. Examples, costs, thresholds, and outcomes are illustrative unless directly cited. Verify current vendor pricing, regional availability, legal obligations, and compliance requirements with qualified professionals before relying on them.

WORTH in 30 Seconds

Before adopting any technology, pattern, or practice, score five questions from 1 (clear no) to 5 (strong yes, backed by evidence):

Dimension Question
Weigh the problem Is the pain concrete, frequent, and business-critical?
Outcome > overhead Does the benefit clearly exceed the total cost?
Right-sized for the team Can the current team build and run it confidently?
Time-to-value Does it deliver value within the quarter?
Horizon flexibility Can you reverse or adapt the choice later?

The rule: proceed past discussion only with an evidence-backed “yes” on at least 3 of 5, a total of 15+/25, and no dimension at 1 (a 2 needs explicit mitigation). Otherwise: simplify, pilot, or wait.

Run your first five-minute scorecard →

Table of Contents

Part I: Foundation

  1. Introduction: The Problem with Technology Dogmas
  2. The WORTH Principle: Core Framework
  3. Decision Scorecard & Methodology

Part II: Deep Dive

  1. Expanded Dimensions
  2. Real-World Application
  3. Practical Examples

Part III: Domain Applications

  1. Code Principles
  2. Acronym Analysis
  3. Architecture Decisions
  4. Common Dogmas Debunked

Part IV: Operationalization

  1. Integration Points
  2. Anti-Patterns & Failure Modes
  3. Measurement & Validation
  4. Operationalizing the Framework

Part V: Extended Applications

  1. Case Studies
  2. Blind Spots Addressed

Appendices

Closing

Part I: Foundation

1. Introduction: The Problem with Technology Dogmas

Software engineering is drowning in principles. KISS, DRY, YAGNI, SOLID, STUPID, CUPID; the list grows monthly. Each promises clarity, yet teams still waste months on Kubernetes setups they don’t need, microservices that slow them down, and clean code rules that add more ceremony than value.

The problem isn’t the principles themselves. The problem is treating them as universal laws rather than context-dependent tools.

The Missing Question

Behind every architectural debate, every technology choice, every process adoption, one question gets skipped:

Is it worth it, here, now, for us?

Not “is it best practice?” Not “what does Big Tech do?” Not “what’s trending on Hacker News?”

Worth it. In your context. With your team. On your budget. For your timeline.

Why Context Matters More Than Dogma

Consider these common scenarios:

Language Wars: Developers argue whether Python, Go, or Rust is “best”, ignoring that the answer depends entirely on your domain, team skills, hiring market, and performance requirements.

Clean Code Extremism: Teams wrap every primitive in a Value Object because a book said so, adding hundreds of lines of boilerplate to a throwaway migration script.

“You Are Not Netflix”: A three-person startup burns four weeks setting up Kubernetes because “it’s how you scale”, never shipping the product that needed to prove market fit first.

Process Bloat: A seed-stage company adopts SAFe with two-week sprints and full ceremonies, while the market shifts weekly and competitors move daily.

Each of these decisions might be right somewhere. They’re wrong when blindly applied without asking whether they’re worth it in your specific situation.

What WORTH Provides

WORTH is a meta-principle that sits above all other engineering guidelines. It doesn’t replace KISS, DRY, or YAGNI; it helps you decide when to apply them.

Think of it as a five-question litmus test you run before adopting any technology, pattern, or practice:

If you can’t answer “yes” to at least three of these five questions with clear evidence, don’t adopt it yet. Revisit when your context changes.

Who This Framework Serves

Tech Leads & Staff Engineers: Battling over-engineering and decision fatigue while trying to ship reliably.

CTOs & Founders: Controlling cloud spend, reducing talent churn, and ensuring technology choices support business goals.

Senior Developers: Needing guard-rails to push back on dogma without seeming obstinate.

Teams of Any Size: From solo developers to hundred-person engineering orgs, context-aware decision-making scales.

How to Use This Document

This isn’t a book you read cover-to-cover and shelve. It’s a working framework you return to every time you face a technology decision.

If you’re a solo developer or indie hacker, skip directly to the Solo Developer / Indie Hacker Mode section (embedded in Section 16) for simplified guidance tailored to one-person projects.

Start with the core framework in Section 2. Use the scorecard in Section 3 on your next decision. Refer back to domain-specific chapters as needed.

2. The WORTH Principle: Core Framework

WORTH is a pragmatic litmus test for every architectural, process, or tooling choice.

The Five Questions

Letter Question Signals It’s NOT Worth It
W – Weigh the problem Is the pain concrete, frequent, and business-critical? Buzz-driven adoption, vague “might need it later”
O – Outcome > overhead Will this clearly improve customer or developer outcomes more than it costs in time, money, or complexity? Long payback period, marginal uplift, hidden ops costs
R – Right-sized for the team Can the current team build and run it confidently within working hours? Reliance on “future hires”, hero culture, steep learning curves
T – Time-to-value Does it accelerate delivery now or within the quarter you’re planning? Multi-month migrations delaying revenue or feedback
H – Horizon flexibility Does it keep sensible options open without locking you into tech or vendors? Irreversible bets, vendor lock-in, explosive surface area

Rule of Thumb

You need ALL of these to proceed beyond discussion:

  1. Qualitative check: Crisp, evidence-based “yes” on at least three of the five letters
  2. Quantitative check: Total score ≥ 15/25 (see detailed scoring in Section 3)
  3. Floor check: No score of 1. Any score of 2 requires explicit mitigation before adoption.

Why the checks matter:

If any check fails, don’t adopt it yet. Improve the weak dimension, run a reversible pilot, or re-evaluate when context changes.

Why WORTH Sits Above Other Principles

KISS tells you to keep solutions simple once you’ve decided to build them.

DRY avoids duplication inside the chosen solution.

YAGNI warns against speculative features.

WORTH precedes all of them: it ensures you’re even solving the right problem at the right scale before optimizing its internal design.

W – Weigh the Problem

Start by quantifying the pain you’re trying to solve.

Key Questions:

Red Flags:

Good Signals:

Example: A team debates adopting GraphQL. The current REST API requires frontend developers to make 5-7 calls to render a dashboard. This happens for every page load across 10,000 daily users. That’s real, frequent, measurable pain. ✓

Counter-example: A team considers GraphQL because “it’s flexible and modern.” No evidence of current API causing problems. ✗

O – Outcome > Overhead

Calculate whether the benefit outweighs the total cost.

Key Questions:

Red Flags:

Good Signals:

Example: Migrating to a PaaS costs $400/month but saves 20 developer hours/month on infrastructure management. At $100/hour blended rate, that’s $2,000 in value for $400 cost. Clear win. ✓

Regional Cost Note: The examples use approximate mid-2020s US market rates. Adjust for your region:

Recalculate ROI using your actual rates to ensure accurate WORTH scoring.

Counter-example: Adding Kubernetes to reduce deployment time from 5 minutes to 3 minutes, costing 2 weeks of setup and ongoing complexity. Marginal gain, huge overhead. ✗

R – Right-Sized for the Team

Assess whether your team can realistically build and maintain this.

Key Questions:

Red Flags:

Good Signals:

Example: A team of experienced Java developers considers Spring Boot vs. Micronaut. Both fit their skill set and mental models. ✓

Counter-example: Same Java team considers rewriting everything in Rust to “learn something new” despite zero Rust experience and aggressive ship dates. ✗

T – Time-to-Value

Determine if the investment delivers value within your planning horizon.

Key Questions:

Red Flags:

Good Signals:

Example: Adopting feature flags delivers value immediately: first feature uses flags for safe rollout within one sprint. ✓

Counter-example: Rewriting the entire app to microservices with no customer value until completion 8 months from now. ✗

H – Horizon Flexibility

Evaluate whether this choice keeps options open or creates lock-in.

Key Questions:

Red Flags:

Good Signals:

Example: Using PostgreSQL (open standard, multiple hosts, dump/restore works everywhere) vs. proprietary cloud database with custom query language. PostgreSQL wins on flexibility. ✓

Counter-example: Building entire architecture around a startup vendor’s beta SDK with no export functionality. ✗

When WORTH Doesn’t Apply

WORTH is built for operational adoption decisions: tools, platforms, architecture, process. Handle these differently:

3. Decision Scorecard & Methodology

The Five-Minute Scorecard

Use this lightweight process for any technology, pattern, or practice decision.

Step 1: State the Issue (One Sentence)

Force clarity by writing a single sentence problem statement.

Example: “Release lead-time increased from 3 days to 9 days after adding the reporting service.”

Step 2: Score Each Dimension (1-5)

Dimension Score Evidence
W – Weigh the problem 1-5 How big, frequent, and critical is the pain?
O – Outcome > overhead 1-5 Does benefit clearly exceed cost?
R – Right-sized team 1-5 Can we build and run this confidently?
T – Time-to-value 1-5 Do we see value within current quarter?
H – Horizon flexibility 1-5 Can we reverse or adapt this choice?

Scoring Guide:

Scoring convention: when comparing options for the same decision, score W identically for every option. W rates the problem, not the solution; option-specific strengths and weaknesses belong in O, R, T, and H.

Step 3: Calculate Total

Add the five scores:

Calibration Note: These thresholds are author heuristics, not validated benchmarks. Adjust how much process you use, but keep the floor check:

Re-calibrate quarterly based on decision outcomes. If many “proceed” decisions fail, inspect which dimension was over-scored before changing thresholds.

Step 4: Document in ADR

Record your scoring in an Architecture Decision Record so the rationale is searchable and auditable when context changes.

Worked Examples

Example 1: Kubernetes for a 3-Developer Startup

Problem Statement: “We need to deploy our app somewhere and want it to scale.”

Dimension Score Evidence
W – Weigh 2 Problem is tiny; current single-server traffic is under 100 users/day
O – Outcome 1 Setup takes 2-4 weeks; benefit is handling 10x traffic we don’t have
R – Right-sized 1 No Kubernetes experience on team; steep learning curve
T – Time-to-value 1 Delays MVP by 3+ weeks; could use PaaS and ship this week
H – Horizon 3 k8s is flexible but overkill creates lock-in to complexity

Total: 8/25

Verdict: ✗ Skip. Use a PaaS (Heroku, Render, Railway) or simple VM with CI/CD. Re-evaluate at 10,000+ daily active users or when hiring experienced SRE.

Example 2: Microservices vs. Modular Monolith (Series B Scale-Up)

Problem Statement: “Release collisions between teams slow deployment frequency.”

Dimension Score Evidence
W – Weigh 4 Three teams frequently blocked waiting for others’ deploys
O – Outcome 3 Faster independent deploys, but ops overhead and latency increase
R – Right-sized 3 Team has two SREs with microservices experience
T – Time-to-value 2 Migration takes 4-6 months; could start with modules first
H – Horizon 4 Can phase in gradually; doesn’t require full rewrite

Total: 16/25

Verdict: Pilot only. Start with a modular monolith using strong boundaries and module-owned data. Extract 1-2 services only as an evidence-gathering pilot. Measure delivery and operational impact before expanding.

Example 3: Custom SQL Abstraction Layer

Problem Statement: “We duplicate the same query patterns in five different files.”

Dimension Score Evidence
W – Weigh 2 Annoyance but only affects 2-3 developers occasionally
O – Outcome 3 Reduces duplication, increases consistency; minimal maintenance
R – Right-sized 5 Team is SQL-savvy; this is a simple abstraction
T – Time-to-value 4 Can implement in one day; immediate benefit
H – Horizon 4 Easy to remove or replace if we change databases

Total: 18/25

Verdict: ✓ Worth a lightweight pilot. Low cost, raises consistency, reversible in a day. Note the floor rule: W=2 means the pain is minor, so the mitigation is to time-box the work and keep it easy to delete. Drop it the moment it competes with higher-priority work.

Embedding the Scorecard in Your Workflow

Pull Request Template

Add a “WORTH Check” section:

## WORTH Assessment (for non-trivial changes)
- [ ] **W** – What problem does this solve? Is it concrete and frequent?
- [ ] **O** – Does the benefit exceed the complexity added?
- [ ] **R** – Can the team maintain this without heroic effort?
- [ ] **T** – Does this accelerate or delay current goals?
- [ ] **H** – Is this decision reversible or does it create lock-in?

**Total Score**: __/25
**Clear yes count**: __/5
**Any score of 1?** __ If yes, do not adopt.
**Any score of 2?** __ If yes, explicit mitigation required before adoption.
**Unknowns?** __ Replace unknowns with evidence through a spike or pilot.
**Hard constraints passed?** Security / compliance / privacy / procurement: __

Architecture Decision Record (ADR)

Include WORTH scoring in every ADR:

## Context
[Describe the problem]

## WORTH Analysis
| Dimension | Score | Rationale |
|-----------|-------|-----------|
| Weigh | 4 | Daily friction costing 5 dev hours/week |
| Outcome | 4 | Saves `$10k/mo`; costs `$2k` setup + `$500/mo` |
| Right-sized | 3 | Two engineers have experience; third will train |
| Time-to-value | 4 | First value in 2 weeks; full ROI in 3 months |
| Horizon | 5 | Standards-based; multiple vendors available |

**Total**: 20/25 → **Pilot only (15-20 band); adoption requires 21+ and a clean floor**

## Decision
[Record the choice]

## Consequences
[Expected outcomes]

## Revisit Trigger
Re-score if: team shrinks below 2 experienced operators, cost increases 2x, or migration takes >4 weeks

Quarterly Architecture Review

Rotate a “devil’s advocate” who re-scores one live component each quarter and proposes simplification if it drops below 15. Section 11 shows the full ritual, including a worked retro example. This catches accumulating complexity and prevents zombie technologies.

Part II: Deep Dive

4. Expanded Dimensions

The five core WORTH questions are enough for most decisions. For high-stakes choices, expand your evaluation with these additional lenses.

Cost of Delay & ROI Horizon

A choice can be “cheap” but still catastrophic if it postpones revenue or feedback.

Why It Matters: Every week you delay shipping is lost learning, lost revenue, and lost market position. Quantifying this forces trade-offs into the open.

How to Measure:

Example: A feature migration to microservices delays shipping by 3 months. If each month of delay costs $50k in lost revenue, the migration carries a hidden $150k cost even if engineering time is “free.”

Diagnostic Questions:

Cognitive Load & Team Topology

High-skill tools are fine until cognitive load crosses what a single team can safely juggle.

Why It Matters: Teams have limited mental bandwidth. Each new technology, pattern, or service consumes attention that could go toward delivering features.

How to Measure:

Example: A team already managing React, Node.js, PostgreSQL, Redis, and AWS considers adding Kafka. If they’re already near cognitive limits, adding Kafka might tip them into constant firefighting.

Diagnostic Questions:

Further Reading:

Delivery Performance (DORA Metrics)

If a decision lowers deployment frequency or raises change-fail percentage, beware: you may have traded adaptability for “best practice” theater.

Why It Matters: DORA research associates software-delivery performance metrics with organizational outcomes. Use the traditional Four Keys where useful, and check current DORA reports before treating any benchmark as canonical.

How to Measure:

Traditional DORA Four Key Metrics:

Metric What It Measures Example High-Performance Signal
Deployment Frequency How often you deploy to production Frequent, low-friction production deploys
Lead Time for Changes Time from commit to production Short, predictable flow from change to release
Time to Restore Service Time to recover from incidents Fast restoration after customer-impacting issues
Change Failure Rate % of deployments causing incidents Low rate of release-caused incidents

Note for Non-Continuous Teams: DORA metrics reflect continuous delivery practices. If your team operates on planned release cycles (quarterly enterprise software, regulated deployments), substitute relevant metrics:

The principle remains: measure delivery effectiveness in your context.

Example: A team adopting microservices sees deployment frequency drop from 5/week to 1/week because coordinated releases require more planning. The architecture might be “better” in theory but worse in practice.

Diagnostic Questions:

Further Reading:

Risk & Uncertainty (Real Options Thinking)

Model upside as options, not certainties. Real Options thinking values flexibility over dogma and lets you stage investments.

Why It Matters: Technology decisions under uncertainty are options, not obligations. You can defer commitment, pilot, and learn before full investment.

How to Apply:

Example: Instead of rewriting the entire app in a new framework, extract one module, ship it, measure results, then decide whether to continue.

Diagnostic Questions:

Further Reading:

Strategic Context (Wardley Mapping)

Wardley Mapping keeps you from reinventing commodities (e.g., bespoke logging) while spotting areas worth in-house mastery.

Why It Matters: Not all components deserve equal investment. Commodities should be bought; differentiators should be built and mastered.

How to Use:

Example: Custom logging is a commodity: use Datadog or ELK. Your unique pricing algorithm is a differentiator: build and optimize it.

Diagnostic Questions:

Further Reading:

Bias Gate

Sunk-cost fallacy, resume-driven development, or “that’s how FAANG does it” can skew scoring. Force a devil’s-advocate review to neutralize bias.

Why It Matters: Cognitive biases make us defend past investments, chase novelty, or copy others without understanding context.

Common Biases:

How to Counter:

Diagnostic Questions:

Compliance & Security

Regulated domains may hard-block certain stacks. Map legal, security, privacy, and procurement constraints early or your WORTH score is fiction.

Why It Matters: Legal requirements trump architecture preferences. Compliance failures carry fines, shutdowns, and reputation damage.

Common obligations and control frameworks:

Diagnostic Questions:

Op-Ex vs. Cap-Ex (Total Cost of Ownership)

TCO often dwarfs initial build effort. Factor on-call load, infra cost curves, licensing, and vendor escalations.

Why It Matters: A “free” open-source tool that requires 40 hours/month of maintenance costs $48k/year at a $100/hour blended rate.

Components of TCO:

How to Calculate:

Example assumption: Kubernetes costs zero to download but may require dedicated SRE time. A PaaS may cost more per unit but need far less operations attention. Use your actual compensation, vendor pricing, support, and on-call costs before comparing TCO.

Environmental & Social Impact

Energy footprint or community support can be differentiators in hiring and PR.

Why It Matters: Green tech attracts talent and customers. Open-source contributions build community goodwill and reduce vendor lock-in.

Considerations:

Diagnostic Questions:

Market Timing & Competitive Landscape

Early adoption can yield moat-building knowledge or saddle you with a dying ecosystem.

Why It Matters: Bleeding-edge technology can become an asset (early expertise) or a liability (abandoned by vendors).

How to Assess:

Diagnostic Questions:

The Extended WORTH Canvas

For high-stakes decisions, use this expanded canvas:

## Problem Statement
[One sentence + cost of delay]

## Options Considered
1. Baseline (do nothing or minimal change)
2. Incremental tweak
3. Ambitious leap

## Scoring Table
| Dimension | Option 1 | Option 2 | Option 3 | Scrutiny |
|-----------|----------|----------|----------|----------|
| W – Weigh | 4 | 4 | 4 | High |
| O – Outcome | 2 | 4 | 3 | High |
| R – Right-sized | 5 | 4 | 2 | High |
| T – Time-to-value | 5 | 3 | 1 | High |
| H – Horizon | 4 | 4 | 2 | Medium |
| **Core WORTH** | **20** | **19** | **12** | Unweighted |
| Cost of Delay | 4 | 3 | 1 | Discussion lens |
| Cognitive Load | 5 | 3 | 1 | Discussion lens |
| Delivery Impact | 3 | 4 | 2 | Discussion lens |
| Risk | 5 | 3 | 2 | Discussion lens |
| Strategic Fit | 3 | 4 | 5 | Discussion lens |

*W is identical across options: it rates the problem, not the solution.*

## Bias Check
- Option 1: Low risk might mean stagnation
- Option 2: Balanced but requires discipline
- Option 3: Exciting but high failure risk

## Decision
[Chosen option + rationale]

## Kill Criteria
Revert if: [Specific measurable conditions]

## Review Date
[Auto-remind 90 days later]

5. Real-World Application

A Cookbook Workflow

This process works for a one-page ADR or a 50-team program.

Step 1: Snapshot the Pain

Write one sentence. Make it numeric if possible.

Example: “Release lead-time ballooned from 3 days to 9 days after adding the reporting service.”

Step 2: Generate Three Options Minimum

Always consider baseline, incremental, and ambitious approaches.

Label Description Estimated Effort
A – Baseline Keep monolith, add read-replica database 2 weeks
B – Incremental Extract reports into separate process + queue 6 weeks
C – Ambitious Full microservice split + Kubernetes autoscaling 12 weeks

Step 3: Score Every Option Across WORTH + Extended Lenses

Use a 1-5 scale. Mark unknowns as U, not as a number. A U means “not enough evidence for adoption”; run a spike or pilot to replace it with evidence.

Dimension Option A Option B Option C
W – Weigh 4 4 4
O – Outcome 2 4 3
R – Right-sized 5 4 2
T – Time-to-value 5 3 1
H – Horizon 4 4 2
Core Total 20 19 12

Step 4: Highlight Biggest Sensitivity

Flag critical assumptions.

Example: Option C only becomes viable if we hire two SREs in the next 30 days (unlikely). Mark as red flag.

Step 5: Decide + Set Kill Switch

Make the call and define failure conditions.

Decision: Pick Option B (extract reports into separate process). Option A totals higher (20), but its Outcome score of 2 has no available mitigation: a read replica speeds queries without decoupling releases, which is the stated pain. B is the highest-scoring option that actually addresses the problem; run it as a pilot (15-20 band).

Kill Switch: If DORA lead time stays above 5 days after 2 sprints, rollback to Option A and revisit.

Step 6: Calendar a Review

Set auto-reminder 90 days later in your ADR system to revisit the score with new data.

6. Practical Examples

Except where a specific company is named and publicly documented (such as Amazon Prime Video below), the cases and figures in this document are illustrative composites of common patterns, not measurements from a single named organization.

Case 1: Three-Developer Bootstrapped SaaS Debates Kubernetes

This revisits Example 1 from Section 3, now with the business context attached.

Context:

WORTH Outcome: Not worth it

Rationale:

Total: 8/25

Verdict: ✗ Skip. Use a PaaS (Railway, Render, Heroku). k8s adds 4+ weeks with zero customer value. Re-evaluate at 10,000+ DAU or when hiring experienced SRE.

Illustrative path: Deploy on a PaaS, ship the MVP quickly, and revisit infrastructure only after deployment, reliability, or cost pain becomes concrete.

Case 2: Fintech Scale-Up (Series C) Considers Microservices

Context:

WORTH Outcome: Full migration scores below the line; pilot the staged extraction instead

Rationale (scoring the full 10+ service migration):

Total: 14/25

Verdict: ✗ for full microservices (below 15, and T=1 fails the floor check). But the pain is real (W=4), so pilot the hybrid path: extract the strongest bounded context first, measure delivery and operational impact, and expand only with evidence. (Case Study 2 in Section 15 scores this same composite option-by-option; the staged extraction lands at 20/25, pilot band.)

Illustrative pilot path:

  1. Extracted payments service (high isolation, PCI boundary)
  2. Ran for 3 months, measured deployment frequency (+30%)
  3. Extracted auth service
  4. Kept reporting and admin in monolith (low change rate, high coupling)

Result: Hybrid architecture. Teams ship independently where it matters. Avoided microservices sprawl.

Case 3: Amazon Prime Video’s Targeted Service Consolidation

Context: Amazon reported that one Prime Video audio/video monitoring workload reduced infrastructure cost by about 90% after consolidating a distributed serverless design into a single-process service running on EC2/ECS. The original Prime Video Tech post has not stayed at a stable URL; InfoQ’s May 2023 summary is a reliable secondary reference (see Further Reading below).

Why It’s a Key Example: This was not an abandonment of microservices. It illustrates that even at massive scale, architectural choices are component-specific, not all-or-nothing dogmas.

Original Problem: Needed to scale quality monitoring across thousands of streams.

Initial Distributed Approach:

WORTH Re-evaluation (scores are the author’s retrospective interpretation of the public write-up):

Total: 9/25 (after implementation)

Reported change: The monitoring workload was consolidated into a single process while keeping logical module boundaries. Amazon reported infrastructure cost reduction of about 90%.

Lesson: Revisit WORTH scores regularly (quarterly for live components, yearly at minimum for settled decisions). Scale and cost assumptions can flip, making previously “correct” architecture wrong. Also: architectural decisions are component-specific, not all-or-nothing. You can consolidate one service while keeping others distributed.

Further Reading:

Part III: Domain Applications

7. Code Principles: Applying WORTH to Clean Code, SOLID, and Object Calisthenics

WORTH is a meta-filter. Before adopting any coding rule (Uncle Bob’s Clean Code, Jeff Bay’s Object Calisthenics, SOLID principles), run the five questions.

How WORTH Sits Above Code Principles

If the rule says… Ask with WORTH… Worth it when… Not worth it when…
“Wrap every primitive in a Value Object” (Object Calisthenics #3) O – Outcome > overhead: Does the extra class reveal real behavior or validation? Domain-heavy codebases (money, dates, IDs) where bugs are expensive One-off scripts, data processing, throwaway ETL
“Functions should do one thing” (Clean Code) R – Right-sized: Do we have time to refactor, and will it help juniors reason faster? Core modules touched daily, high change rate Legacy subsystem slated for decommission in 3 months
“No ‘else’ statements” (Object Calisthenics #2) H – Horizon flexibility: Does banning else keep options open, or push us into contorted polymorphism? Code that thrives on polymorphic behavior (strategy engines) Simple data flows where a guard clause reads clearer
“Depend upon abstractions, not concretions” (SOLID-D) W – Weigh the problem: Are we actually swapping implementations? Plugin systems, multi-cloud adapters One cloud, one database, stable for years

Key Point

The original rule books give general guidance. WORTH makes sure they’re cost-effective in your context, today.

Practical Integration

Design Doc Header

## Which Principle Are We Invoking?
Clean Code: "Functions should do one thing"

## WORTH Score
- [ ] W – Weigh: Functions currently 200+ lines, causing 3 bugs/week
- [ ] O – Outcome: Refactor saves 5 hours/week debugging
- [ ] R – Right-sized: Team comfortable with Extract Method pattern
- [ ] T – Time-to-value: Complete in 3 days
- [ ] H – Horizon: Easier to test and modify going forward

**Clear yeses**: 4/5 → qualitative gate passed; confirm with the full 1-5 scorecard and floor check before adoption

Pull Request Bot

If fewer than 3 of the 5 letters are a clear yes (a failing scorecard), or exactly 3 (a borderline pass), tag #possible-over-engineering for reviewer attention.

Retro Audit

Quarterly, pick one principle adopted last quarter. Re-run WORTH. If score dropped (team changed, scope shifted), schedule removal or simplification.

Outcome: Balanced Engineering

Using WORTH with clean code rules prevents two extremes:

  1. Dogma-driven engineering: Blindly applying every rule because “the book says so”
  2. Chaos-driven shortcuts: Rejecting discipline because “we’re moving fast”

Instead, every guideline must pay rent in the form of clearer code, faster delivery, or lower defects that outweigh its cognitive and calendar cost.

8. Acronym Analysis: Running WORTH Against Common Principles

STUPID – Six Code Smells to Avoid

What It Is: Singleton, Tight-coupling, Untestability, Premature-optimization, Indescriptive naming, Duplication

WORTH Check: Outcome > overhead – Will refactoring pay back quickly in fewer bugs or faster changes?

Worth It: Core modules touched daily; every hour saved in debugging repays fast

Not Worth It: Throwaway migration script that dies next sprint

CUPID – Joyful Code Properties

What It Is: Composability, Unix-philosophy, Predictability, Idiomatic, Domain-based

WORTH Check: Right-sized for team – Can your devs design tiny, composable units without paralysis?

Worth It: Green-field services where micro-features ship independently

Not Worth It: Legacy blob where carving out composable pieces freezes delivery

FIRST – Test Quality Principles

What It Is: Fast, Independent, Repeatable, Self-validating, Timely

WORTH Check: Time-to-value – Do cleaner tests shorten feedback loops enough to justify extra mocks and fixtures?

Worth It: High-change domains (pricing engines, rules) where hours matter

Not Worth It: Stable ETL job touched twice a year; quick smoke test is cheaper

INVEST – User Story Criteria

What It Is: Independent, Negotiable, Valuable, Estimable, Small, Testable

WORTH Check: Weigh the problem – Is story churn causing rework or developer idle time?

Worth It: Distributed teams sprinting in parallel needing clear boundaries

Not Worth It: Solo developer on hobby app; sticky notes beat fine-grained backlog

SMART – Goal-Setting Framework

What It Is: Specific, Measurable, Achievable, Relevant, Time-bound

WORTH Check: Horizon flexibility – Does locking target and date help focus, or stifle exploration?

Worth It: Delivery roadmaps where dates affect marketing or compliance

Not Worth It: Early R&D spikes where discovery is the whole point

ACID vs. BASE – Database Guarantees

What It Is: ACID (Atomicity, Consistency, Isolation, Durability) vs. BASE (Basically-Available, Soft-state, Eventually-consistent)

WORTH Check: Outcome > overhead – Which failure hurts worse: stale reads or blocked writes?

ACID Worth It: Banking ledger behind a queue

BASE Worth It: Feed counters, analytics dashboards

CAP Theorem – Distributed Systems Trade-offs

What It Is: Consistency, Availability, Partition tolerance; under a network partition, you must choose between Consistency and Availability

WORTH Check: Risk & uncertainty – Which guarantee keeps revenue safest under network splits?

Choose AP (Availability + Partition): Global SaaS where an up-to-date cart is less critical than staying online

Choose CP (Consistency + Partition): Stock trading engine; tolerate brief downtime for correctness

Using This Table

  1. Name the acronym you’re tempted to enforce
  2. Run WORTH questions (+ risk lens if stakes high)
  3. If < 3 clear “yes” answers, drop or postpone

Result: Every principle earns its keep instead of bloating rituals or code.

9. Architecture Decisions: Monolith, Microservices, Infrastructure

Monolith vs. Microservices

This is the most contentious architecture debate. WORTH cuts through the noise.

When Monolith Wins

WORTH Profile:

Signals:

Example: Early-stage SaaS, internal tools, MVP validation

When Microservices Win

WORTH Profile:

Even this best-case profile tops out around 20/25, deliberately in the pilot band: microservices earn adoption through a measured pilot, not through the scorecard alone.

Signals:

Example: Scale-ups post-Series B, organizations with 40+ engineers

The Hybrid Middle Ground: Modular Monolith

WORTH Profile: Often scores well because it preserves delivery speed while adding boundaries

Characteristics:

When It’s Best: Often useful for teams that need clearer boundaries but do not yet need independent deployment for every domain.

Infrastructure Decisions

Bare VM vs. PaaS vs. Kubernetes

Option W (Problem) O (Outcome) R (Team) T (Time) H (Horizon) Total
Bare VM 3 (same problem) 4 (cheap, fast) 5 (everyone knows) 5 (deploy today) 3 (harder to scale) 20
PaaS 3 (same problem) 5 (instant value) 5 (no ops needed) 5 (deploy today) 4 (vendor lock manageable) 22
Kubernetes 3 (same problem) 3 (powerful but heavy) 2 (need expertise) 1 (weeks to setup) 5 (max flexibility) 14, fails floor

Illustrative scores for a small-to-mid product team. W is identical across options: it rates the deployment problem, not the platform.

Default for many small-to-mid product teams without special infrastructure constraints: Start with PaaS or a simple VM. Treat vendor names as examples, not endorsements.

When k8s may become worth evaluating:

10. Common Dogmas Debunked

Dogma 1: “X Is the Best Language”

Why People Repeat It: Tribal pride, blog benchmarks, echo chambers

Reality Check: Match runtime, ecosystem, hiring market, and performance envelope to your needs. Switching costs eclipse elegance.

WORTH Analysis:

Situation Language Choice Why
ML/Data Science Python Ecosystem (NumPy, PyTorch, scikit-learn)
Network Services Go Concurrency, deployment simplicity
Systems Programming Rust/C++ Performance, memory safety
Web Backends Node.js, Python, Ruby, Go Team skill + ecosystem fit

When It Pays Off: Domains with clear incumbent (Python for ML, Go for network daemons)

When It Hurts: Polyglot hobby projects that quietly become production: ops chaos, talent shortage, fragmented tooling

WORTH Question: Does this language choice improve outcomes more than the cost of switching, hiring, and maintaining two stacks?

Dogma 2: “Code Must Follow Every Clean Code Rule”

Why People Repeat It: Books sell certainty; lint rules give easy metrics

Reality Check: Each rule adds lines, indirection, review time. Measure gains in defect rate or comprehension, not aesthetic purity.

Spectrum:

WORTH Question: Does this clean code practice reduce bugs or speed changes more than the boilerplate costs?

When It Pays Off: Core libraries touched daily where bugs are costly

When It Hurts: Short-lived scripts, migration throwaway code, experiments racing deadlines

Dogma 3: “You Need Kubernetes and Microservices from Day One”

Why People Repeat It: Copying Big Tech success stories without context

Reality Check: k8s ⇒ steep cognitive load; microservices ⇒ extra latency, ops, observability. Ask: “Will a single VM + CI keep us shipping faster for the next 12 months?”

The “You Are Not Netflix” Principle:

WORTH Question: Does the complexity pay off before we run out of runway?

When It Pays Off: Multiple cross-functional teams needing independent deploys, strict uptime SLOs

When It Hurts: Three-dev startup chasing product-market fit with < $1k/month budget

What to Do Instead:

  1. Start with PaaS or single server
  2. Add modules/boundaries in monolith
  3. Extract 1-2 services when pain justifies it
  4. Scale infrastructure when revenue supports it

Dogma 4: “Every Team Needs Heavyweight Process”

Why People Repeat It: Comfort for managers, audit trails for enterprises

Reality Check: Process overhead ∝ team size × coupling. Bureaucracy kills flow in small squads.

Spectrum:

WORTH Question: Does this process improve delivery speed or just create overhead?

Team Size Appropriate Process
1-3 devs Kanban board, weekly sync, monthly retro
4-10 devs Scrum-lite: standups, sprints, retros
10-50 devs Scrum + architecture review + quarterly planning
50+ devs Shape Up, SAFe, or custom scaled framework

When It Pays Off: Regulated scale-ups (fintech, health) where compliance beats velocity

When It Hurts: Seed-stage ventures where market changes faster than sprint review cycle

Part IV: Operationalization

11. Integration Points: Embedding WORTH in Daily Workflow

Pull Request Template

Add a WORTH delta checkbox for non-trivial changes:

## WORTH Delta (for changes adding complexity)

Does this change raise our cognitive load score?
- [ ] Adds new technology/framework
- [ ] Increases coupling between modules
- [ ] Requires new operational expertise

If yes to any, WORTH justification required.

**WORTH Score**: __/25 (if applicable)

CI Pipeline Integration

Post DORA metric diffs against the feature branch so reviewers see immediate delivery impact:

# .github/workflows/worth-check.yml
name: WORTH Metrics

on: pull_request

jobs:
  dora-diff:
    runs-on: ubuntu-latest
    steps:
      - name: Calculate lead time diff
        run: |
          # Compare current branch vs main
          # Post diff to PR comment

Visible Metrics:

Backlog Refinement Rule

Every story that adds durable complexity should link to its parent WORTH-scored ADR. Size alone is not enough; use this for new technologies, service boundaries, irreversible vendor choices, security/compliance impact, or material ongoing cost.

Example:

## Story: Add GraphQL endpoint for dashboard

**Parent ADR**: #147 (GraphQL Migration - WORTH Score 17/25)

**Justification**: Reduces frontend API calls from 7 to 1; expected to improve load time by roughly 40%

Quarterly Operations Review

Rotate a “devil’s advocate” who:

  1. Selects one live component or technology
  2. Re-scores it with current context
  3. Proposes kill/simplify plan if score < 15

Example Retro:

12. Anti-Patterns & Failure Modes

Anti-Pattern 1: Resume-Driven Development

Symptom: Technology choice justified by “industry standard” or “I want to learn this”

Why It Happens: Individual career goals override business needs

Guard-rail: Bias gate: mandatory counter-proposal from someone outside the team who argues for simpler alternative

Example:

Anti-Pattern 2: Cargo-Cult Microservices

Symptom: Dozens of tiny services, yet releases still tied together; DORA lead time unchanged or worse

Why It Happens: Copying Big Tech patterns without understanding context

Guard-rail: Check DORA lead time quarterly. If unchanged after 6 months, merge modules back

Example:

Anti-Pattern 3: Hero Ops

Symptom: One expert owns critical infrastructure (k8s, database); vacations freeze deploys

Why It Happens: Hiring/training gaps; over-reliance on individual

Guard-rail: Treat a “Right-sized” score below 3 as a hero-ops red flag; the required mitigation is at least two on-call capable developers

Example:

Anti-Pattern 4: Analysis Paralysis

Symptom: Extended WORTH scoring sessions lasting days; no decision made

Why It Happens: Perfectionism, fear of commitment, unclear decision-maker

Guard-rail: Time-box WORTH canvas to 2 working days maximum. Default to lowest-cost prototype if still undecided.

Example:

Anti-Pattern 5: Gaming the Score

Symptom: Scores are artificially inflated or manipulated to justify a predetermined outcome. This nullifies the framework’s purpose, turning it into a tool for validating biases rather than challenging them.

How Teams Game the Score:

  1. Inflating scores: Marking unknowns or subjective opinions as 5/5 without evidence.
  2. Cherry-picking evidence: Ignoring contradictory data that would lower a score.
  3. Skipping the bias gate: Not having a neutral party or “devil’s advocate” review the scoring.
  4. Ignoring re-scoring: Never revisiting past decisions to validate the original score against real-world outcomes.

Guard-Rails:

13. Measurement & Validation: Learning Whether WORTH Helps

Metrics That Matter

Track these to learn whether WORTH-driven decisions age well in your context:

1. Software Delivery Metrics

Metric How WORTH May Help
Deployment Frequency T (Time-to-value) ensures choices accelerate shipping
Lead Time for Changes O (Outcome) prevents overhead that slows delivery
Time to Restore R (Right-sized) ensures team can operate without heroics
Change Failure Rate W (Weigh) focuses on real problems, not speculative fixes

How to Measure: Use production deploy, incident, and change history over comparable windows. PR-local CI data can provide useful proxies, but it is not the same as DORA measurement.

2. Cognitive Load Surveys

Quarterly developer survey:

Rate agreement 1-5 (1 = strongly disagree, 5 = strongly agree):

1. I feel overwhelmed by the number of technologies I need to know
2. I often need help to debug production issues
3. Large parts of our systems are unclear to me
4. I have no time to learn new skills

Score < 12 = Healthy
Score 12-16 = Warning
Score > 16 = Overloaded (simplify stack)

3. Decision Cycle Time

Track time from “proposal” to “decision made”:

Goal: Reduce decision paralysis while maintaining quality. Fill in your own baseline; this document does not claim a universal improvement.

4. Rollback Rate

What percentage of decisions get reversed within 6 months?

5. Cost Metrics

Track infrastructure and operational costs quarterly:

## Q3 2024 Infra Costs

| Category | Cost | Change vs. Q2 |
|----------|------|---------------|
| Cloud (AWS) | `$8,200` | -15% (removed unused k8s cluster) |
| SaaS Tools | `$3,400` | +5% (added monitoring) |
| On-call Hours | 40 hrs | -30% (simplified stack) |

**WORTH Impact**: Killed over-engineered service mesh (score dropped to 9/25). Saved `$1,500/month` + reduced on-call burden.

Example: Tracking One Decision

Decision: Migrate from REST to GraphQL for dashboard API

Initial WORTH Score: 17/25

Measurement Plan:

  1. Week 0: Baseline page load time (2.1s), API call count (7), developer velocity (8 stories/sprint)
  2. Week 4: Pilot on one dashboard
  3. Week 8: Full rollout
  4. Week 12: Re-measure

Results:

Re-score WORTH: 15/25 (dropped from 17)

Action: Pause further rollout. Keep GraphQL for existing dashboards but don’t expand. Re-evaluate in 6 months after team upskills.

14. Operationalizing the Framework

To make WORTH a team-wide habit, it needs to be embedded in the daily rituals of software development. The goal is to make the five questions an automatic, low-friction part of decision-making.

Start Small

  1. Pick one pending decision (technology, architecture, process).
  2. Fill out the WORTH scorecard (5 minutes solo to draft, 15 minutes max with the team).
  3. Share the result and make a call with explicit kill criteria.
  4. Set a 90-day reminder to re-score the decision with real data.

Repeat this process. The five questions soon become the default first response to any new proposal, long before anyone books a meeting about it.

Part V: Extended Applications

15. Case Studies: WORTH in Practice

These case studies are illustrative composites of common patterns; the figures are representative rather than measured from a single named company.

Case Study 1: Bootstrapped SaaS – Railway Over Kubernetes

Context:

Pain Point: Need to deploy app; considering infrastructure options.

Options:

Option Setup Time Monthly Cost Ops Burden
A: DigitalOcean VM 1 day €20 Medium (manual deploys)
B: Railway PaaS 2 hours €20-40 Minimal
C: Kubernetes (EKS) 2-3 weeks €150+ High

WORTH Scores:

Dimension VM Railway k8s
W – Weigh 2 2 2
O – Outcome 4 5 1
R – Right-sized 4 5 1
T – Time-to-value 5 5 1
H – Horizon 3 4 3
Total 18 21 8

W is scored identically across options: the deployment problem is the same whichever platform solves it. The k8s column matches the scorecard for this same scenario in Sections 3 and 6.

Decision: Railway (score: 21/25)

Rationale: Maximize time-to-value. Can ship MVP this week. Budget-friendly. Easy migration path if growth demands it.

Implementation:

Composite outcome shape:

Lessons Learned:

Case Study 2: Fintech Scale-Up – Hybrid Microservices

Context:

Pain Point: Teams blocking each other 2-3 times/week waiting for deployment windows. Lead time increased from 3 days to 7 days.

Options:

Option Migration Time Complexity Team Impact
A: Tighten module boundaries 1 month Low Minimal
B: Extract 2-3 services (payments, auth) 3-4 months Medium 2 teams affected
C: Full microservices (10+ services) 8-12 months High All teams disrupted

WORTH Scores:

Dimension A: Modules B: Hybrid C: Full
W – Weigh 4 4 4
O – Outcome 2 4 3
R – Right-sized 5 4 2
T – Time-to-value 5 3 1
H – Horizon 4 5 4
Total 20 20 14

W is identical across options (the deployment-collision problem is the same regardless of solution). Option A’s O reflects that tightening an already-modular monolith has limited headroom against release coupling.

Decision: Option B (Hybrid) - score tied with A, but better horizon flexibility tipped decision

Rationale:

Implementation:

Composite outcome shape:

WORTH Re-score: Revisit after the pilot using measured delivery, incident, cost, and audit data.

Lessons Learned:

16. Blind Spots Addressed

This section tackles objections and contexts the main flow doesn’t address head-on: four dogmas with strong followings, additional decision lenses, and a dedicated mode for one-person projects. Where Section 10 debunks dogma broadly, these entries drill into specific high-stakes cases.

Dogmas Revisited

Dogma: “TDD Is Mandatory or You’re Reckless”

Why It’s a Dogma: TDD can add indirection and slow exploratory work; even its creators debate universal value.

Reality Check: TDD shines for:

TDD struggles for:

WORTH Application:

Context W O R T H Total Verdict
Billing engine 5 5 4 3 5 22 ✓ TDD worth it
One-off migration 2 1 3 1 3 10 ✗ Post-hoc tests sufficient

Dogma: “Go All-In on Serverless”

Why It’s a Dogma: “Never think about servers again!” marketing obscures trade-offs.

Reality Check:

WORTH Application:

Scenario Cold Start Acceptable? Debugging Needs Lock-In Risk Verdict
Image resize API Yes (async) Low Low ✓ Lambda
Real-time chat No High High ✗ PaaS/VM

Illustrative rollback story: A startup moved to Lambda for all APIs. Debugging production issues took roughly 5x longer (no SSH, CloudWatch delays). After a few months, it moved the critical path back to EC2 and kept async jobs on Lambda. Hybrid won.

Dogma: “Event-Driven Architecture Is Always Better”

Why It’s a Dogma: Loose coupling sounds great in theory.

Reality Check:

WORTH Decision Matrix:

Use Case Consistency Needs Traceability Latency Verdict
Order processing Strong High Low ✗ Request/response + DB transaction
Analytics events Eventual OK Medium High OK ✓ Event stream

Dogma: “GraphQL Fixes Every API Problem”

Why It’s a Dogma: Flexible queries sound universally better than REST.

Reality Check:

WORTH Sidebar:

API Pattern When to Use
REST Simple CRUD, public APIs, need HTTP caching
gRPC Internal services, performance-critical, typed contracts
GraphQL Rich client queries, reducing round trips, mobile apps

Other Lenses

Security & Compliance Guard-Rails

Problem: WORTH can score “yes” but legal requirements veto the choice.

Solution: Add compliance checklist before scoring:

## Compliance Gate (complete BEFORE WORTH scoring)

- [ ] PCI DSS requirements (if handling card payments)
- [ ] HIPAA requirements (if handling US health data as a covered entity or business associate)
- [ ] GDPR/LGPD (if handling EU/Brazil personal data)
- [ ] SOC 2 controls (if selling to enterprises)
- [ ] Threat model reviewed (if internet-facing)

If ANY are blocked, the option is outside the adoption set until qualified security, legal, compliance, or procurement reviewers resolve the block.

Data Modeling & Storage

Why It Matters: SQL vs. NoSQL wars rival language wars in heat/lack of nuance.

WORTH Application:

Storage Type When It Wins When It Loses
PostgreSQL (relational) Relational data, strong transactional invariants, complex queries Schemaless flexibility, certain horizontal-scaling patterns
MongoDB (document) Flexible document model, denormalized reads, tunable consistency Complex joins or invariants if the model is poorly designed
Redis Caching, sessions, pub/sub Primary data store, durability critical
NewSQL (CockroachDB) Need both ACID + horizontal scale Low-write workloads, budget-constrained

WORTH Question: Does our data access pattern justify the operational complexity of this database?

Observability: How Much Is Enough?

Dogma: “Full OTEL stack or you’re flying blind”

Reality: Observability has costs (infrastructure, cognitive load, vendor bills). Size it by SLOs, blast radius, architecture complexity, and MTTR goals rather than user count alone.

WORTH Spectrum:

Context Logging Metrics Tracing APM Cost Shape
Low criticality / simple architecture Structured logs Basic uptime/errors None or sampled None Low
Customer-facing / moderate complexity Centralized logs RED metrics Critical paths Optional Medium
High criticality / distributed architecture Standardized telemetry SLO dashboards Distributed tracing APM where useful Higher

WORTH Question: Does the observability investment reduce MTTR enough to justify the cost?

People Dogmas

Dogma 1: “Only hire seniors”

Reality: Balanced teams (seniors + mid-level + juniors) often outperform all-senior teams due to:

WORTH Question: Does hiring exclusively seniors improve delivery more than the 2x salary cost?

Dogma 2: “10x engineer myth”

Reality: “10x teams” exist; “10x solo engineers” are rare and create bus-factor risk.

WORTH Question: Are we building for individual heroics or team resilience?

Solo Developer / Indie Hacker Mode

Blind Spot: Most books ignore one-person projects.

WORTH Solo Mode:

Default Answers for Solo Devs:

One-Page Solo Canvas:

## Solo Dev WORTH Checklist

- [ ] Do I actually need this, or is it "best practice" theater?
- [ ] Can I build and run this alone in < 1 week?
- [ ] Will this help me ship faster or just add complexity?
- [ ] Can I reverse this in a weekend if it doesn't work?

If < 3 checks pass, skip it.

Appendices

Appendix A: WORTH Canvas (One-Page Template)

# WORTH Decision Canvas

**Date**: ___________  **Decision-Maker**: ___________  **Reviewer**: ___________

## Problem Statement (one sentence)
[What pain are we solving?]

**Cost of Delay**: $______/week OR _______ hours/week

---

## Options Considered

| Option | Description | Estimated Effort |
|--------|-------------|------------------|
| A (Baseline) | | |
| B (Incremental) | | |
| C (Ambitious) | | |

---

## WORTH Scorecard (1-5 scale, unknown = U)

| Dimension | A | B | C | Scrutiny |
|-----------|---|---|---|----------|
| **W** – Weigh the problem | | | | High |
| **O** – Outcome > overhead | | | | High |
| **R** – Right-sized team | | | | High |
| **T** – Time-to-value | | | | High |
| **H** – Horizon flexibility | | | | Medium |
| **CORE TOTAL** | | | | |

### Extended Lenses (optional, high-stakes only)

| Dimension | A | B | C |
|-----------|---|---|---|
| Cost of Delay | | | |
| Cognitive Load | | | |
| Delivery Impact | | | |
| Compliance | ✓/✗ | ✓/✗ | ✓/✗ |

---

## Bias Check

**Potential biases influencing this decision**:
- [ ] Sunk-cost fallacy
- [ ] Resume-driven development
- [ ] Conformity ("everyone's doing it")
- [ ] Availability bias

**Counter-argument for preferred option**: ___________

---

## Decision

**Chosen**: Option ____

**Rationale**: ___________

**Kill Criteria** (revert if):
1. ___________
2. ___________

**Review Date**: ___________ (90 days from decision)

---

## Signatures

**Approved**: ___________ (Tech Lead)
**Reviewed**: ___________ (Devil's Advocate)

Appendix B: Decision Tables Consolidated

Table 1: Common Dogmas vs. Reality

Dogma Reality Check Pays Off When Hurts When
“X is the best language” Match runtime, ecosystem, hiring market to needs Domain has clear incumbent (Python-ML, Go-network) Polyglot chaos; ops fragmentation
“Follow every Clean Code rule” Weigh defects saved vs. boilerplate added Core libraries touched daily Throwaway migration scripts
“Start with k8s & microservices” Cognitive load check; outcome > overhead Multi-team, strict SLO scale-ups 3-dev startup pre-PMF
“Heavyweight process for all” Time-to-value; process ∝ team size Regulated enterprises Seed-stage pivoting weekly
“TDD everywhere” Test value vs. exploration speed Safety-critical long-lived code Green-field spikes, notebooks
“Serverless cures ops” Cold-start vs. observability trade-off Spiky traffic, budget tied to usage Steady low-latency workloads
“EDA > request/response” Traceability vs. loose coupling Multi-consumer async workflows Single-team ACID transactions
“GraphQL over REST” Query flexibility vs. caching complexity Rich client queries, mobile Simple CRUD, public APIs

Table 2: Acronyms Through WORTH Lens

Acronym Core Idea WORTH Check Worth It Not Worth It
STUPID Six code smells to avoid Outcome > overhead Daily-touched modules One-off scripts
CUPID Joyful code properties Right-sized team Green-field micro-features Legacy blob refactor
FIRST Fast, independent tests Time-to-value High-change domains Yearly ETL jobs
INVEST Story slicing criteria Weigh the problem Parallel distributed teams Solo dev hobby projects
SMART Goal-setting framework Horizon flexibility Compliance-driven roadmaps R&D exploration spikes
ACID/BASE DB guarantee trade-offs Outcome > overhead Banking (ACID), Social feeds (BASE) -
CAP Distributed systems trade Risk lens Trading (CP), SaaS cart (AP) -

Table 3: Architecture Decision Matrix

Pattern When It Wins WORTH Red Flags
Monolith Single team, emerging domain, rapid iteration Team > 15, deployment conflicts, different scaling needs
Modular Monolith 10-40 devs, clear modules, shared DB acceptable Need polyglot, PCI isolation, independent scaling
Microservices 40+ devs, multiple teams, clear bounded contexts < 10 devs, single team, shared transactions common
Serverless Spiky traffic, async jobs, cost ∝ usage Real-time requirements, deep debugging needs

Table 4: Infrastructure Choice Matrix

Option Setup Time Monthly Cost Ops Burden Flexibility Best For
Bare VM 1 day $20-100 Medium Low Solo dev, learning, static sites
PaaS 2 hours $20-500 Minimal Medium Startups, small teams, rapid iteration
Kubernetes 2-4 weeks $200+ High Very High 50+ services, multi-cloud, large teams

Appendix C: Additional Dogmas Deep-Dive

Infrastructure as Code (IaC)

Dogma: “Everything must be IaC (Terraform, Pulumi) or you’re unprofessional”

Reality Check: IaC shines in multi-environment estates (dev, staging, prod × 3 regions = 9 configs). For disposable infrastructure, manual setup may be fine; for production, at minimum script or document the provisioning well enough to rebuild it.

WORTH Application:

Infrastructure Scale IaC Worth It? Why
1-2 disposable VMs ✗ Usually no Manual setup may be faster; fewer changes
1-2 production VMs Depends Script or codify enough to recover and audit
3-10 servers, multiple envs ✓ Yes Reproducibility saves time; disaster recovery
50+ resources, multi-region ✓ Definitely Manual management impractical; drift prevention critical

Feature Flags for Every Toggle

Dogma: “Feature flags everywhere for continuous deployment”

Reality Check: Flags multiply configuration drift and kill readability when product has < 100 users and tight feedback loops.

WORTH Application:

Stage Flag Complexity Worth It? Rationale
MVP (< 100 users) High (10+ flags) ✗ No Just deploy and monitor
Growth (1k-10k users) Medium (targeted rollouts) ✓ Yes Gradual rollout reduces risk
Scale (100k+ users) Managed (kill-switch only) ✓ Definitely Instant rollback critical

Daily Stand-ups & Two-Week Sprints

Dogma: “Agile = daily standups + two-week sprints, non-negotiable”

Reality Check: Async tools (Linear, Loom, written standup posts) can yield comparable visibility for remote micro-teams without synchronous overhead.

WORTH Application:

Team Situation Synchronous Standups Async Updates
Co-located team, 5-10 devs ✓ 15-min standup works -
Remote team, < 5 devs, tight communication ✗ Overhead > value ✓ Daily Slack updates
Remote team, 10+ devs, coordination heavy ✓ Yes, but 2-3x/week ✓ + async for off-days

Long-Running Release Branches

Dogma: “Only merge via long-running release branches (Git Flow)”

Reality Check: Trunk-based development with small PRs often substantially reduces merge conflicts and lead time.

WORTH Application:

Deployment Frequency Git Flow Trunk-Based
Monthly releases ✓ Acceptable -
Weekly releases Painful merges ✓ Better flow
Daily+ releases ✗ Bottleneck ✓ Essential

Domain-Driven Design (Full Bounded Contexts)

Dogma: “DDD means full bounded-context everything with event storming and aggregates”

Reality Check: Heavy DDD artifacts pay off in domain-rich areas with complex business rules, not in simple CRUD SaaS v1. Event storming, aggregates, and bounded contexts are tools to apply selectively, not a package deal.

WORTH Application:

Domain Complexity Full DDD Lite DDD (just bounded contexts)
Simple CRUD (admin panel, CMS) ✗ Overkill ✓ Basic modules enough
Medium (e-commerce, SaaS) Selective use ✓ Yes, skip event sourcing
Complex domain rules (payments, clinical workflows, trading) ✓ Often justified -

Appendix D: Glossary & Further Reading

Glossary

ADR (Architecture Decision Record): Document capturing important architectural decisions with context, options, and rationale.

DORA Metrics: Four key metrics (deployment frequency, lead time, MTTR, change failure rate) measuring software delivery performance; DORA research associates them with organizational outcomes.

Cognitive Load: Mental effort required to understand and operate a system; teams have finite capacity.

Cost of Delay: Economic impact of postponing value delivery; approximated as (weekly value) × (weeks delayed).

PaaS (Platform as a Service): Cloud hosting that abstracts infrastructure (Heroku, Railway, Render).

Real Options: Financial concept applied to software: valuing the right to defer decisions until more information is available.

TCO (Total Cost of Ownership): Full lifecycle cost including development, operations, maintenance, and opportunity costs.

Wardley Mapping: Strategic planning tool showing component evolution from genesis to commodity.

Essential Reading

Books

  1. Accelerate by Nicole Forsgren, Jez Humble, Gene Kim The science behind DORA metrics and high-performing teams

  2. Team Topologies by Matthew Skelton, Manuel Pais Organizing teams for fast flow and cognitive load management

  3. The Principles of Product Development Flow by Donald Reinertsen Cost of Delay, queuing theory, and economic decision-making

  4. Wardley Maps by Simon Wardley Strategic context and component evolution

  5. Working Effectively with Legacy Code by Michael Feathers Pragmatic refactoring without dogma

  6. A Philosophy of Software Design by John Ousterhout Complexity management and design trade-offs

Online Resources

How to Contribute

This framework improves through real-world application. Share your WORTH decisions:

Template:

## Decision: [Title]
**Context**: [Team size, domain, constraints]
**WORTH Score**: __/25
**Outcome**: [What happened]
**Lesson**: [What you'd do differently]

Submit case studies and feedback to: github.com/jeansossmeier/worth

Conclusion

The Core Message

Great engineering isn’t about accumulating principles. It’s about consistently choosing the simplest solution that delivers outsized value in your context.

WORTH turns that judgment into a repeatable, team-wide habit by asking five questions:

  1. Is the pain real and business-critical? (Weigh)
  2. Does benefit exceed cost? (Outcome)
  3. Can the team operate it? (Right-sized)
  4. Does it deliver value soon? (Time)
  5. Does it keep options open? (Horizon)

If you can’t answer “yes” to at least three with clear evidence, don’t adopt it yet.

What Makes WORTH Different

Not another best practice: WORTH sits above principles, helping you decide which to apply when.

Context-aware: What works for Netflix doesn’t work for your three-person startup. WORTH forces explicit context.

Measurable: Scorecards, DORA metrics, and TCO calculations replace gut feelings with evidence.

Iterative: Quarterly re-scoring catches when “right” becomes “wrong” as context shifts.

Actionable: Templates, checklists, and automation make it operational, not theoretical.

Start Tomorrow

  1. Pick one pending decision (technology, architecture, process)
  2. Fill out the WORTH scorecard (5 minutes)
  3. Share with your team for bias check
  4. Make the call with explicit kill criteria
  5. Set 90-day reminder to re-score with real data

That’s it. One decision. Five questions. Repeat.

Over time, asking “Is it worth it?” becomes muscle memory. Your team stops chasing hype and starts compounding value.

Final Thought

The best engineers don’t memorize frameworks. They ask better questions.

Is it worth it?

Everything else follows from that.

Go build something worth building.