The Ruha Method, Part 2: Isolate and Verify

You changed three things and it started working. The user is happy, the ticket is closed, and you have no idea which change fixed it. Three weeks later the same fault comes back, and you start from nothing — because you learned nothing the first time.

Part 1 taught you to define a problem before touching it. This lesson is about what happens next: how to find the cause without guessing, and how to know the fix actually worked rather than hoping it did.

It is the least glamorous part of technical work and the part that separates people who fix things from people who make things stop happening for a while.

Lesson 2.1 — Reproduce it before you repair it

There is a real difference between a fault you have seen and a fault you have been told about. Until you have made the problem happen yourself, you are working from someone else's description — and descriptions are lossy.

When I take a ticket, the first thing I try to do is make the problem happen. Not because I doubt the person. Because "it will not print" means eleven different things, and I cannot tell which one it is from the sentence.

Reproducing it well means being specific about the conditions:

• Same person. Does it happen to them, or to anyone on that machine?
• Same device. Does it follow the person to a different computer?
• Same steps. The exact sequence, not a summary of it. People skip the step that matters.
• Same conditions. On the office network or at home. Morning or afternoon. First thing after logging in, or after hours of work.

When you genuinely cannot reproduce it

Some faults are intermittent, and intermittent faults do not respond to more effort. Trying harder to reproduce something that happens twice a week is time spent badly.

What works instead is shifting from reproduction to observation. Ask the person to record exactly when it happens — the time, what they were doing, what was open. Two or three data points usually reveal a pattern that no amount of clicking would have found. A fault that only appears on Monday mornings is telling you something. A fault that appears after four hours of use is telling you something else.

Say plainly that you have not reproduced it yet. A ticket that honestly reads "not yet reproduced, gathering occurrences" is more useful to the next person than one that claims a fix nobody tested.

Lesson 2.2 — Work the chain in order

In Part 1 you met the chain that runs through every system: person, device, network, identity, application, data, service. Scope told you roughly where on that chain to stand. This lesson is about walking it deliberately, one rung at a time, once you already know where you are standing.

Most wasted troubleshooting time comes from starting in the middle — reinstalling an application when the account is locked, or rebuilding a profile when the network is down. The order below is the same chain, expanded slightly and given a direction of travel. Each rung either clears a whole layer or stops you there.

The order is not arbitrary. It runs from the cheapest question to the most expensive one, and from the most common cause to the least. Asking "does this happen to anyone else?" costs one message and can eliminate six rungs.

Where people go wrong

The most common mistake is skipping to the rung that matches your expertise. If you know applications well, every problem looks like an application problem, and you will spend an hour in settings before discovering the licence lapsed.

The second most common is stopping at the first rung that produces a plausible story. Plausible is not the same as verified. If you find a suspicious setting on rung 6, that is a hypothesis — you still have to change it and prove it mattered.

Lesson 2.3 — Change one thing, then verify

This is the discipline the whole lesson is built around, and it is the one most often abandoned under pressure.

When someone is waiting and you are not sure, the temptation is to change several things at once because one of them will probably work. It usually does. And the cost is that you have learned nothing, the person who picks up the same fault next month starts from zero, and you have possibly introduced two changes that will cause a different problem later.

The loop is short:

Knowing how to undo a change before making it is the part people skip. In a shared environment it is not optional — a setting you changed on a whim at four o'clock is a setting nobody can explain at nine the next morning.

Verify against the complaint

A fix is not finished when the error message stops appearing. It is finished when the person who reported it can do the thing they originally could not do.

Those are different. An error can stop appearing because the underlying operation now fails silently. A file can open and still be the wrong version. A printer can accept the job and produce nothing.

Go back to the problem statement you wrote in Part 1 and test against that sentence. If the statement said "Maria cannot print to the upstairs printer from her laptop," then the verification is Maria, upstairs printer, her laptop. Not you, at your desk, on a different machine.

How hard to verify depends on what breaks if you are wrong

Not every fix deserves the same scrutiny, and pretending otherwise wastes time you do not have.

• Low consequence — a shortcut that was in the wrong place. Confirm it works once and move on.
• Medium consequence — a setting change affecting one person's daily work. Test it, then check back the next day.
• High consequence — anything touching access, permissions, shared data or security. Test it, document it, and confirm with someone else that it did what you intended. If it is destructive, stop and get a second opinion before, not after.

The question that sets the level is simple: if I am wrong about this, who finds out, and how badly?

The exercise: work a change log

Take a fault you are dealing with now, or the last one you resolved, and fill this in. It takes about ten minutes and it is the whole lesson in practice.

Most people find the same thing when they do this honestly: they made more changes than they remembered, and they cannot say which one worked. That discovery is worth more than the rest of the lesson.

The principle underneath this

Change one thing, then check whether it worked — and know how to put it back before you start.

This is not about computers. It is how you find a fault in anything with more than one moving part: a recipe that stopped working, a process at work that used to run smoothly, a car that makes a noise. Change several things at once and you get an outcome. Change one and you get an explanation. The second one is the only kind you can use again.

Where this stops

Some faults cannot be isolated with the access one person has. In a centrally managed environment, the setting causing the problem may be pushed by a policy you cannot see, applied by a team you are not on. You can work the chain correctly and still end at a locked door.

That is not a failure. Escalating with a clear change log — here is what I ruled out, here is what I changed, here is what I observed — is a genuinely better outcome than continuing to guess, and it makes you the person the next team actually wants to hear from.

And if the problem involves data loss, security, or anything you cannot reverse, the right move is to stop before changing anything and ask someone. Careful method does not substitute for authority you do not have.

The short version

Make the problem happen before you try to fix it. Work the chain from Part 1 in order — person, device, network, service, account, application, external — because each rung eliminates a layer for the price of one question. Change one thing at a time, know how to undo it before you make it, and write down what you did. Verify against the original complaint rather than against the error message, and scale how hard you verify to what breaks if you are wrong.