doubt-driven-development

Doubt-Driven Development

Overview

The first workable idea gets defended; a better second idea never gets considered. This skill institutionalizes doubt at the moments it pays: before committing to a decision that is expensive to reverse, deliberately attack it — enumerate failure modes, steelman one alternative, and try to break the plan on paper where breaking is free. Doubt is a tool applied at decision points, not a mood applied to everything.

When to Use

• Architecture decisions: module boundaries, offline/sync model, state management approach (see android-architecture)
• Data migrations: Room schema changes, DataStore format changes — anything touching persisted user data (see android-data-persistence)
• Adopting or replacing a dependency the codebase will grow around
• Public or cross-team API contracts (see api-and-interface-design)
• minSdk/targetSdk bumps and platform-behavior migrations (see deprecation-and-migration)

Skip when: The decision is cheap to reverse (naming, private helpers, a screen's internal layout). Applying this to every choice is procrastination with extra steps.

Core Process

Step 1: Write the Decision Down First

1. One paragraph, falsifiable: what is being decided, what it optimizes for, what it deliberately gives up. If it can't be written down, it can't be attacked.

Decision: store sync state in a Room table per entity (not a global
DataStore flag). Optimizes for per-item retry and conflict tracking.
Gives up: simpler global "is syncing" UI state.

Step 2: Attack It

1. Enumerate concrete failure modes — Android-specific ones first:

- Process death mid-sync: is a row ever stuck in SYNCING forever?
- Migration: what happens to existing rows when the enum gains a value?
- Doze: WorkManager retry backoff vs. per-row retry counts — double retry?
- 10k tasks: does the per-row model create N WorkRequests?

1. Steelman exactly one alternative. Argue for it as its best advocate would — not a strawman you can dismiss: