When to stop and roll back

a rollback is a tool, not a defeat

What it is

Sometimes the right move is to throw away what you have done and start over. It feels like losing time, so it gets postponed to the last — and in the end far more is lost.

This article is about the signs that the moment has come, and about rolling back in a way that keeps what was useful.

Five signs that it is time

The last sign is the most honest. If you open the file and hesitate to change it, that is not caution — it is the code no longer being yours.

How to roll back

Discard uncommitted work

git diff                     # first look at what you are losing
git checkout -- handlers/    # roll back a folder
git checkout -- .            # roll back everything

The first command is mandatory: before throwing something away, check whether there is anything useful in it.

Keep it just in case

If throwing it away feels wrong:

git stash                    # set it aside, return to a clean state
git stash list               # see what is stashed
git stash pop                # bring it back

stash is a rollback with the option to change your mind. A good choice when you are unsure.

Return to a working commit

git log --oneline -5         # find the last working one
git reset --hard <commit>    # go back to it

What to take with you

Rolling back the code is not rolling back your understanding. The failed attempt taught you things you did not know at the start, and they are worth saving before you throw the code away:

• What doesn't work and why. The most valuable part: a dead end once explored need not be walked again.
• The minimal reproduction of the error (article 4.3).
• Tests, if you managed to write any — they survive any rollback.
• Decisions that turned out right. Often one or two parts of a large failed change were correct.

Before I roll these changes back: list what is worth keeping
and what was a dead end. Briefly, as a list.

How to start over

Without walking the same path:

1. A new session. The old context is contaminated (article 4.9).
2. Restate the task, taking into account what you found out. Usually it comes out differently from the first time — a good sign.
3. A plan first (article 3.10). A second run without a plan often leads into the same dead end.
4. Smaller steps. If a large change has failed twice, split the task into three and do the first.

I tried to do X and hit a dead end for this reason: <reason>.
We're starting over. Lay out a plan for a different approach,
and say why it is better than the one that didn't work.

What to look for

A rollback postponed because of the time spent. Two hours are lost either way. The only question is whether you lose a third.

The code rolled back along with the conclusions. The same rake again a week later.

A rollback with no commit behind it. If the last commit was yesterday, a rollback costs a day's work. That is not a rollback problem, it is a commit problem.

"Almost working" as a steady state. If that sentence has been running for three hours, it means "not working".

Cheat sheet