Lesson 49 — Estimating and splitting problems

Exercise 1 — The honest estimate

1. The automatic-assignment estimate:

Well known:  the seats model + the free-seats query (09/10) → 1-2 d (high)
Medium known: the suggestion service (proximity/price, 08's rules)
             + the endpoint + tests → 2-3 d (medium)
Unknown:     the "best seats" policy with the business (what is best?
             center row? together? the price?) → 1-3 d (REAL uncertainty)
Total: 4-8 days, medium confidence. Trigger: if the policy is not defined on day 1,
       I re-estimate and notify (§4: the policy is the business's, not mine).

1. The typical deviation: the "2 h" for "add the expires_in_seconds field to the DTO" (25) took half a day: the calculation in the DTO needed the Clock injected (scope grew to make the calculation testable) — the deviation was SCOPE, not speed: history's lesson: classify the deviation (scope? unknown? interruptions?) before correcting the multiplier.

1. The history's pattern: infra tasks (Celery, compose) underestimated ×1.5-2 (the environment bites); data ones (GDPR export) ×2 (anonymization was 70%); pure-logic ones with the logic already extracted (28) -30% (the earlier refactor PAYS OFF). The calibration: ×1.5 on infra, split data ones further.

Exercise 2 — The vertical split

1. The split (4 days):

1. (1 d)  Suggestion with fake gateway: /suggest endpoint for N people's seats,
          with the simple v1 policy (contiguous, lowest price) + tests + admin demo.
          The business SEES real suggestions on day 1.
2. (1 d)  Reserving FROM the suggestion (the full flow with the prefilled suggestion):
          the flow's E2E exists.
3. (1 d)  Concurrency-safe (10): two simultaneous suggestions, the seat lock;
          the dispute test.
4. (1 d)  The v2 policy with the business (the "best" per THEIR rule) + the edges
          (nearly-full event → suggest alternatives) + final smoke.

1. Piece 1 vertical: model + query + endpoint + tests + demo to the admin — the classic mistake's "just the model" gets rewritten: day 1 delivers the decision the business must confirm (the v1 policy) BEFORE changing it gets expensive (early feedback IS the vertical's purpose).

1. Piece 3 could grow (concurrency is 10's terrain): if it exceeds 3 days, split it: (3a) the dispute's basic lock; (3b) the plateau's load test (36). Each half with its test.

Exercise 3 — The explicit scope

1. The "yes, but" (excerpt): "Automatic assignment ships on day 5 IF: (a) the 'best' policy is defined on day 1 (it is a business decision, not technical); (b) the v1 scope excludes refunds of wrong assignments (the following week) and accessibility-aware suggestions (backlog). Options: (1) scope (a) ships on day 5; (2) if the refund is blocking, we displace 36's presale a week; (3) nobody else touches checkout these days (40's merge)."

1. The 3-day deadline: the options: (a) minimum scope: pieces 1-2 (suggestion + flow) in 3 days WITHOUT armored concurrency (risk: the seat dispute in presale — NOT recommended for a presale); (b) 36's presale gets displaced (cost: the business loses the date); (c) resources: nobody else touches checkout (mitigates merge, not scope). The recommendation: (b) — automatic assignment WITHOUT armored concurrency in a presale is the bug of the year: better the date than the incident (47 tells the consequences).

1. The day-2 message: "The policy component is taking longer (the business defines what 'best' means): the feature ships in 5 days as planned, not 4. I ask for: the policy's definition by Thursday. Alternative if it does not arrive: I ship on day 4 with the v1 policy (contiguous + price) and v2 enters the following week. I propose alternative B if Thursday comes with no definition."

Exercise 4 — The visible plan

1. The sprint plan:

1. The risks: (sandbox/providers: n/a here) (a) the policy undefined → day-1 trigger + alternative B; (b) concurrency surprises (the lock contends more than expected) → 34's test on day 3, not at the end; (c) the alternatives' UX grows → explicit out-of-scope (the backlog).

Exercise 5 — The applied skill

1. Migrating checkout to the separate service: estimate: known (the code to move: the saga already decoupled by 32: 5-8 d), medium (the contract between services + network: 5-8 d), unknown (dual operations, the hot data migration, the rollback: 5-10 d) → 15-26 days in phases: (1) the new service DUPLICATES the flow (strangle: the monolith stays the truth, 53); (2) the per-feature-flag switch to the service for 5% of traffic (46's canary); (3) 100% + the monolith dethrones the code; (4) cleanup (11's contract). Each phase delivers measurable value.

1. The big problem's "yes, but": "The migration is 15-26 days in 4 phases; the alternative: NOT separating (53's modular monolith holds ×10 the current volume for 0 days) or buying the managed gateway (5 d, +200 €/month, vendor lock). I present the three with cost/risk: the out-of-scope decision is the business's."

1. The personal rule (excerpt): "I estimate in ranges with triggers; pieces are vertical with demos; the unknown gets separated and communicated the day it is known (not at the deadline); the deviation gets classified (scope/unknown/interruption) before correcting the method."

Professor's summary

• Range + decomposition + re-estimation trigger: the honest estimate is a contract with review; history calibrates and the deviation gets classified before correcting.
• Vertical pieces with demos (early feedback buys cheap decisions); the explicit out-of-scope beats the mute yes.
• The trade-off is presented by the technician and decided by the business: the problem communicated on time is a plan.