You're previewing the Bennett demo family. Numbers, schedule, and kids are sample data.Start your own
Loading page…
There is a method for finding what broke, and the strange thing about it is that it never needs you to understand the thing you are fixing. Five checks will find one dead bulb in a string of thirty-two. Doubling the string costs you one more check.
Something stops working. The lamp, the printer, the wifi, the bike light, a recipe that came out wrong three times running.
Most people have the same thought: I don't know how this works, so I can't fix it. And then they either poke at it randomly or hand it to someone else.
Here is the surprise. The people who are good at this often do not know how the thing works either. What they have is an order of operations — a set of moves they run in the same sequence on a bike, a router and a batch of cookies. The method does not care what the object is, because the method is not about the object. It is about narrowing down where the fault can possibly be.
Five moves. This is all of it.
You are not trying to understand the machine. You are trying to make the list of possible culprits shorter, and then shorter again.
If it worked on Friday and not on Monday, then something is different, and the fault is living inside that difference. So the first question is never "what is wrong with it" — it is "what is different since the last time this worked?"
Somebody moved it. It got unplugged for the vacuum. There was a power cut. It updated overnight. You used a different brand of flour. Somebody borrowed it. It rained.
Write the differences down, even the ones that sound irrelevant, because "irrelevant" is a guess about a machine you just admitted you do not understand. A list of four differences is already a shorter list than everything that could possibly be broken, and you got it without touching a screwdriver.
Is it plugged in. Is the switch on. Are the batteries dead. Is the cable pushed all the way in at both ends. Is the screen on the right input. Is there paper in it.
These are humiliating to check and they are correct to check first, for a reason that has nothing to do with humility. You are ordering your checks by two things at once: how likely a cause is, and how cheap it is to rule out. Loose connections and flat batteries score high on both — they are extremely common and they take ten seconds.
The interesting causes are rare and expensive to investigate. Doing them first means that when the answer turns out to be a plug, you have spent forty minutes to find it.
Your bike light died. Two candidates: a flat battery — very common, ten seconds to rule out — or a broken wire inside the sealed casing, which is rare and takes twenty minutes to get at. Which do you test first, and what is the actual reason?
This is the powerful one, and it is the reason you do not need to understand the machine.
If you can test half of something at a time, then every single test throws away half of your suspects. Not one suspect. Half of them.
That one condition is the whole requirement, and it is worth saying plainly: halving only works if there is some way to check a half — unplug half the things on the power strip, comment out half the code, leave out half the ingredients, disconnect half the string. If you cannot test a half, you cannot halve, and you are back to going one at a time.
One line before the example, and it is not decoration: this method is for things that are switched off and unplugged. House wiring, gas, and anything that stores an electrical charge are not objects to practise halving on — those are a job for an adult with the right training, and the correct move there is to stop at move 1 and tell someone.
Otherwise, the arithmetic is startling. Watch.
An old string of fairy lights, wired so that one dead bulb kills the whole string. It is unplugged — this is a lights-off, hands-only job. Any one of the thirty-two could be the dead one. Press through and watch the suspect list.
A friend has a string of 1,024 lights with one dead bulb, and can test any half at a time. Roughly how many checks does the halving method need in the worst case?
Halfway through, you will be tempted to change three things at once, because you are impatient and one of them is bound to be it.
Do not. Suppose it works afterwards. What have you learned? That one of three things fixed it, and you cannot say which — so the next time this happens you are starting from nothing again. Worse, two of your three changes are still sitting there, and any of them can turn into the next fault.
So: change one thing. Test. If it did not help, put it back before you try the next one. Otherwise your failed attempts pile up inside the machine and become a second problem, tangled with the first.
A scrap of paper. Two columns: what you did, what happened.
This is not tidiness. It does three concrete jobs. It stops you testing the same thing twice at half past nine when you have lost track. It stops you skipping something you meant to check and now half-remember doing. And it is the first thing any person or repair shop will ask you — "what have you already tried?" — where "um, some stuff" is a much more expensive answer than a list.
Everything you can do to a broken object falls into one of two piles: it narrows down where the fault can be, or it muddies the picture. Some of the muddying ones feel extremely productive. Sort each and read why.
Tap an item, then tap where it belongs
The wifi has been dropping out. You restart the router, move it onto the shelf, and swap the cable — all at once. It works now. What do you actually know?
One more move, and it is the one people leave out.
If the broken thing has a deadline attached — the projector for a talk in twenty minutes, the oven with dinner in it — then partway through you should stop and ask a different question. Not how do I fix this, but what does this actually need to do, and is there another way to get that?
The talk needs the slides visible. A laptop screen turned round to face the room does that. Dinner needs to be hot. The neighbour has an oven.
That is not giving up, and it is not the same move as the fix. It is noticing that fixing the projector was never the goal — it was one route to the goal — and that routes have deadlines while goals do not. Fix it properly afterwards, with the method, and no clock running.
You’re previewing as a parent — nothing here is recorded.
The halving arithmetic is exact and checkable: each test removes half the remaining candidates, so the worst-case number of tests is the number of times you can halve the list. 32 halves to 1 in 5 steps (2^5 = 32), 64 in 6 steps, and 1,024 in 10 steps (2^10 = 1,024). This is binary search, the same reason looking a word up in a sorted list of a million entries takes about twenty steps. The same idea is a real, named tool: `git bisect`, part of the version-control system Git, finds which single change in a project's history broke it by repeatedly testing the midpoint of the untested range rather than checking changes one by one. Halving under the name 'half-split' is standard taught practice in electronics and equipment troubleshooting: divide the system at a midpoint, determine which side the fault is on, and repeat. 'Change one thing at a time' is the controlled-experiment principle: with several variables changed simultaneously, an observed outcome cannot be attributed to any one of them. The fairy-lights string, the bike light and the wifi router are illustrations, not measurements. No figure in this episode is presented as data about the real world; the only numbers are the halving counts, which are arithmetic. Safety note stated in the episode: the worked example is an unplugged string of lights. Mains wiring, gas appliances and anything holding a stored electrical charge are not things to take apart to practise this method on.