Lesson 49 — Estimating and splitting problems

Stack: Soft skills · Project: TicketFlow Status: Published — estimating with honesty and splitting big problems Prerequisite: Lesson 48 — Documentation and ADRs

Objectives

1. Estimate with ranges and declared uncertainty (not with gut numbers): the anchor method, decomposition and history.
2. Split a big problem into vertical deliverables the business can see and the team can finish.
3. Communicate the trade-off when the estimate bites: the structured "yes, but" that beats the mute yes and the dry no.

1. The single-number mistake

The question "how long does this take?" deserves the answer "between X and Y, with this uncertainty" — the single number ("3 days") falsifies reality: known problems have variation, unknown ones (the new gateway, the legacy migration) have REAL uncertainty. The course's method:

Task: outgoing webhooks with signing and retries (17)
- Well known:    HMAC signing + outbox + poller          → 3-5 d   (high confidence)
- Medium known:  queue with backoff + DLQ                → 2-3 d   (medium confidence)
- Unknown:       the provider's sandbox (does it respond? the docs?) → 0-3 d (real uncertainty)
Total: 5-11 days, medium confidence. The trigger: if the sandbox takes >1 d, I re-estimate and notify.

The three pieces: decomposition (each part estimable), the range (explicit uncertainty), and the re-estimation trigger (the condition that turns the range into a number and fires the communication: the estimate is a contract with review, not a fixed promise). And the fairness multiplier: the task estimated "2 h" by someone who knows it well usually takes "half a day" in reality — the knowledge buffer, not the fear one: it is declared inside the range.

2. History: the memory estimation asks for

The best estimation tool is YOUR history (what the course's suite records): the past-tasks table with estimated vs actual. The pattern history reveals (operational Hofstadter's law): 2-day tasks take 3; 2-week tasks take 4 (uncertainty scales more than work). The project's correction: range multiplied by 1.5 for tasks > 1 week, and the big-task question: "is this ONE task or three badly split?" — the answer is almost always the second (§3). History is NOT shared as a weapon (the toxic boss's "you took 2× the estimate"): it is used to calibrate your own ranges.

# docs/estimates/2027-Q4.md — the history
| Task | Estimated | Actual | Deviation | Why |
|---|---|---|---|---|
| Outgoing webhooks | 5-11 d | 9 d | ok | provider's sandbox: 2 d |
| Expiration with Celery | 3 d | 2 d | -1 | the logic already extracted (28) |
| GDPR export | 4 d | 8 d | ×2 | anonymization was 70% of the work |

3. Splitting: vertical deliverables, not horizontal

Splitting the big problem: vertical (each piece delivers end-to-end user value: "record a payment and show it" with the fake gateway) vs horizontal ("first the whole model, then the whole service, then the view" — nothing works until the end, feedback arrives late, and the final integration is the classic hell). The course's splitting (the "gift card purchase" feature, 08):

1. (0.5 d) The GiftCard model + migration + admin: the business SEES the inventory
2. (1 d)   Paying WITH a gift card (the full happy path, fake gateway): the E2E flow exists
3. (1 d)   The card's ledger (08): the money's traceability
4. (1 d)   The edges: insufficient balance (26), expiration (31), concurrency (10)
5. (0.5 d) The real gateway + smoke: the final edge

Each piece: finishable, testable, demonstrable (the business watches the feature grow); the total: 4 days with feedback at every cut. The splitting rule: if a piece exceeds 3 days, split it further (what is THIS piece's happy path?); and piece 1 is not "just the model" — it is model + admin + the first test: vertical too.

4. Communicating the trade-off: the structured "yes, but"

The trade-off the estimate reveals is communicated structured — the mute yes (accepting the impossible date: the deadline cliff) and the dry no ("it can't be done": obstruction without alternatives) are the junior's two communication failures. The "yes, but" format:

"We can have gift card checkout by day X IF:
 (a) the provider's sandbox responds this week (risk: their side, not ours), AND
 (b) the scope is happy path + edges — gift card refunds (the inverse amount)
     is the following week.
 Options if the date does not move: (1) scope (a) is what ships;
 (2) the refund ships if we displace the GDPR export; (3) nobody else touches
 checkout this week (40's merge risk demands it)."

The three pieces: the condition (what must be true), the scope (what is in and what is NOT — the explicit no of scope), and the options (the trade-off's owner is the business: you present, they choose). The craft's golden rule: the problem communicated on time is a plan; communicated mid-sprint, a fire; communicated at the deadline, a resignation.

5. Estimation in the course's world

TicketFlow applies the method: the presale feature (36's turnstile) estimated with the method: known (23's rate limiter: 2 d), medium (the waiting room with SSE, 16: 3-4 d), unknown (the waiting room's UX: 2-4 d with the front) → 7-10 days in 4 vertical pieces (rate limit alone → in-memory queue → Redis queue → polished UX), with the trigger "if the waiting room exceeds 2 d, the MVP ships without it". And the quarter's history fed by commits: estimation is a skill that improves with measurement — 37's thesis (measure before optimizing) applied to time.

Self-assessment

1. Why does the single number falsify, and which three pieces does the honest estimate carry (decomposition, range, trigger)?
2. What does personal history reveal, and how is it used without becoming a weapon?
3. Vertical vs horizontal: why does "the whole model first" fail, and which property does each vertical piece have?
4. Which three pieces does the "yes, but" carry, and who owns the trade-off?
5. The golden rule of communication: what turns the problem into plan vs fire vs resignation?

Continue with the exercises. The solutions only after trying it yourself.