To Yak Shave or Not: The Art of Procrastination in Software Development

September 18, 2023

You sit down to ship a chat component. Four hours later you have upgraded TypeScript, fixed three unrelated type errors, bumped the test runner, and rewritten ESLint. The chat feature has zero lines of code.

That chain has a name.

What is yak shaving?

Carlin Vieri 🔗 coined it at the MIT AI Lab in the 90s, after a Ren & Stimpy gag. The useful meaning is a dependency chain. To do A you must do B. To do B you must do C. C is shaving a yak.

There is a second meaning: busywork you do so you do not have to do A. The title of this post is a joke about that one.

I am talking about the first one. The first one is how real work actually fails.

Is this bike shedding?

No. I mixed these up for years.

Bike shedding 🔗 is Parkinson’s law of triviality. A committee spends 45 minutes on the bicycle shed and two minutes on the reactor. Easy topics attract comments. Hard topics do not.

Yak shaving is usually solo, and the tasks are often real. Bike shedding is usually social, and the task is the wrong size of attention.

A quick test. If you are alone going deeper, it is a yak. If you are in a meeting going wider on something small, it is a shed.

The fixes differ. Yaks get scoped and stashed. Sheds get a decision. “Formatter wins. Next.”

The rest of this post is yaks.

Should you shave it?

Three checks, before you touch it.

Is it blocking? Not “would be nicer.” Can you ship without it.

Is it bounded? Minutes, or “let’s see.” Unbounded yaks eat days.

Does it belong in this PR? A reviewer should describe the diff in one sentence. If the yak breaks that sentence, it is a different PR.

Then:

• Shave it now if it is blocking, bounded, and still the same story.
• Stash it (other branch, other PR) if it is real work that does not belong here.
• Skip it (file an issue) if it is neither blocking nor bounded.

Most yaks I regret were skips pretending to be shaves.

What about the chat component?

Let’s run the same afternoon through the checks.

Outdated TypeScript. Blocking? No. The new utility types are nice. Skip. File “Bump TS.”

The type errors from the upgrade. They never happen, because you skipped the upgrade. That cascade is the thing you are avoiding.

Failing tests. Blocking if they are tests for chat. Skip if they were red on main already. Do not fix unrelated red in a feature PR. You cannot revert that PR without reverting the test fixes too.

ESLint. Skip. Linter setup is its own review.

The chat ships. The yaks become a backlog you can order on purpose, instead of a pile you found at 11pm.

What actually works?

Write the yak down. A scratch file, a TODO at the bottom of the PR. Ten seconds. Most yaks die once they are written. They grow when you are afraid you will forget them.

Park the diff. When the “quick fix” starts touching unrelated files, get it off this branch. git stash 🔗 parks uncommitted work. git worktree 🔗 checks out another branch in another directory without disturbing this one. If the fix does not fit on this branch, you will feel it.

A real timer. “I’ll spend 20 minutes” without a timer is an hour. When it rings, the question is not “am I close?” The question is stash, or another 20.

Notice the second hop. Yak 1 is usually fine. Yak 2 is the warning. By yak 3 you are doing archaeology. The pattern is the hop, not the depth.

If you are three hops in and the original feature is untouched, stop. Commit the detour on its own branch if it is worth keeping. Otherwise stash it. Do not git reset --hard the afternoon away unless you know the SHA you are resetting to.

When should you shave anyway?

The checks say skip. Sometimes you still shave.

The yak will block you next week. Flaky CI, broken local dev, a type error you keep walking around. Pay it once, in its own PR.

You are learning the codebase. Early on, following the chain is onboarding. This expires. Once you know the system, the checks apply.

Outside those, file the issue. Ship the feature. Let the yak grow its coat back.

Written by Zubin Khavarian