Exercise 2: A Lower Fix-Success Rate — Possible Solution
====================================================================

SETUP
------------------------------
    FIX_SUCCESS_RATE = 0.7 (lowered from the chapter's own 0.9)

RESULTS
------------------------------
    ALL-BLOCKING (5 items): average 2.39 rounds
    SELECTIVE-BLOCKING (1 item): average 1.43 rounds
    Extra rounds: 0.96 (67% more)

    (chapter's own 0.9 result: all=1.46, selective=1.11, +31% more)

HOW THE GAP CHANGES
------------------------------
Lowering the success rate from 0.9 to 0.7 more than doubled the
relative gap between the two policies - from 31% more rounds to 67%
more. This isn't a coincidence: the probability that ALL n blocking
items clear in one round is success_rate^n, which shrinks much faster
for large n than for n=1 as success_rate drops. At 0.9, the 5-item
case still clears in one round about 59% of the time (0.9^5); at 0.7,
that drops to about 17% (0.7^5) - a much steeper fall than the 1-item
case (90% -> 70%).

WHY THIS WORKS AS AN ANSWER
------------------------------
This reveals a genuinely important, non-obvious property: the cost of
over-broad blocking gets WORSE, not just proportionally the same, as
the fixes themselves become harder or more ambiguous to get right on
the first try. A team working on genuinely tricky, error-prone code
(where FIX_SUCCESS_RATE is naturally lower) pays an even steeper
penalty for treating every nit as blocking than a team working on
routine, low-risk changes - exactly the situation where selective
blocking's own discipline matters most, not least.