Heuristic
Bisect a large failure domain
When the haystack has structure, stop inspecting every piece of hay.
When it fits
- The searchable space is ordered or divisible and checking every candidate one by one would be expensive.
When to avoid it
- Do not use bisection when candidates interact non-monotonically, the midpoint cannot be tested or the failure classification is unstable.
Why it matters
Split the search space into two meaningful parts and run a test that tells you which side still contains the changed behavior. Keep the implicated half and split again. This works especially well for revision history, layered systems and ordered pipelines when the state can be classified consistently.
An example
If a regression appeared somewhere between two releases, binary-search the revision history instead of reading every commit.
Check your result
Each round removes a substantial part of the search space without changing the property you are testing.
Keep this limit in mind
- Do not use bisection when candidates interact non-monotonically, the midpoint cannot be tested or the failure classification is unstable.
Evidence and sources
Google SRE describes bisection as repeatedly splitting a large system in half to narrow a possibly faulty component; Git bisect applies binary search to ordered revision history.
Bisection needs a meaningful ordered search space and a reasonably testable distinction between the two states.
Effective Troubleshooting · Simplify and reduce; bisection