
Don't Shave That Yak (2005) - vsrev
https://seths.blog/2005/03/dont_shave_that/
======
opportune
Yak shaving is an inevitable, unavoidable part of working in a large company
with mature (or rather: conservative and safe) engineering practices.

A feature I’m working on right now involves a ridiculous amount of knowledge
of the service component architecture and release process because making any
change coordinated across two different hot services with different release
schedules is absolutely hellacious. So even though customers will barely
notice the change, I have to do all this release and flag and migration and
analysis work simply because people actually use and depend on our service and
we have to be really careful not to break it.

It’s not necessarily a bad thing. If we didn’t have to yak shave, it would
mean we either weren’t making money, didn’t care about our customers, or
didn’t do anything important. In 2005, maybe most people weren’t working on
hot services with complex architectures that people depended on. But imagine
what would happen if the tens of thousands of people working on AWS all
collectively decided to not shave yaks when they updated their services.

On an individual basis, your decision to not shave a yak might save time and
effort. At scale, it increases your error rate. If you have thousands of
developers and hundreds of components/services to keep track of, issues are
already an inevitability, and you’re increasing the rate at which issues would
occur by a lot.

~~~
celticmusic
One thing I'd like to add to this.

Software Developers will often be tempted to automate the yak shaving away so
they don't really have to deal with it all. This is a good attitude to have,
but when combined with automation it can also be dangerous. I've seen many
automated solutions run off on their own doing entirely the wrong thing. It's
very often safer to slow down, build tools to assist, but have a human there
to push the go button. It's not as sexy, and if you're scale is large enough
you're also building tools to help with analysis. But in the long run you'll
avoid problems.

------
jrockway
You should be careful about how you manage your time. There is an art to
decide where to draw the line. For this super-contrived example that literally
involves breaking into a zoo to get from an animal a part that can be bought
off the shelf with same-day delivery... I am not sure that the answer is
"don't buy a new hose." You could just pay the cash toll to drive across the
Tappan Zee Bridge. Get a great hose, wash your car, and continue to ignore
your neighbor whose pillow you ignored.

In general, you should have a cost and benefit attached to every action you
are planning. Buying a hose is super easy and solves a lot of problems; you
can start watering your garden again, you can wash your car, you can spray
your kids. The cost is low, the benefit is high, so you should consider it
today. At the bottom of the chain is "break into a zoo and shave a wild
animal". The benefit is low, you can buy yak hair on Amazon. The cost is high,
you're likely going to be maimed AND end up in prison. So don't do that!

This is a super dumb example and we shouldn't even be discussing it.
Management consultants always have a contrived example where their advice
sounds good because the example is bad. This is that.

~~~
RangerScience
This indicates both side of yak-shaving. The chain of requirements in the
contrived example is (IMO) deliberately silly, and misses what you're
(correctly) pointing out: it's not yak shaving if it's building capability...

...unless you know you won't - or don't know that you will - benefit from that
boosted capability. Then it's back to yak shaving.

------
ken
Having tried both ways, I have the opposite view.

Skip all the extra steps and just take a shortcut, and you'll fix one problem
today -- and tomorrow you'll run into three consequences of this shortcut, and
have to take yet more shortcuts. The next 25 problems that cross this path
will be just as hard, and they'll require their own shortcuts.

But fix the 5 sub-problems necessary to fix this the Right Way today (no
matter how crazy), and at the end of the day, you will have the Right Fix in
place. Plus, you'll be one step closer to solving those 25 other problems that
cross through this path.

When solving a problem, you always get to choose whether to take on more tech
debt, or pay off some existing tech debt. People almost never choose to pay
off tech debt, so every step is one step closer to that inflection point where
the entire project is too complex for anyone to work on, and you have to scrap
it and start over.

~~~
iudqnolq
> But fix the 5 sub-problems necessary to fix this the Right Way today (no
> matter how crazy), and at the end of the day, you will have the Right Fix in
> place. Plus, you'll be one step closer to solving those 25 other problems
> that cross through this path.

Unless tomorrow you learn you need to build something completely different.
This is an age old debate, and doing it technically "Right" isn't the be-all-
end-all. "Move fast and break things" is dumb, and so is it's inverse.

Now, that doesn't mean the truth is the happy medium. It's somewhere in
between, weighed to one side. I don't know which. But this is a tension, and I
don't think we can afford to ignore either side.

~~~
bencollier49
Which side it happens to be is on entirely context-driven. If the object of
"yak shaving" happens to be a mathematical proof, then the yak must be shaved.
But if you have to get a system working within five minutes to stop your
company losing ten million pounds, then the yak can remain unmolested.

~~~
SAI_Peregrinus
Sometimes there's an easy way around. With the article's example, you buy an
EzPass (or call the tolls-by-mail number & pay the extra fee for that vs
EzPass). Then you don't need to borrow your neighbour's EzPass, or return the
pillow, or restuff the pillow, or shave the yak. Likewise for many real
systems, often one of the intermediate steps has a better alternative.

------
drewg123
" _Doing it well now is much better than doing it perfectly later_ "

That sounds fine until hundreds of developers make this choice every single
day, and your project is so riddled with technical debt that forward progress
becomes hard to muster. I'll be the first to admit that I postpone or neglect
Yak Shaving myself.

If we think about it the other way around, if we shaved yak every single time,
then the herd would be shaved, and we'd be able to work without so many
distractions.

I guess the big problem with Yak Shaving, at least for a dayjob, is that it
doesn't always count towards making forward progress toward your goals or
OKRs, or whatever we want to call them. I think we need to recognize the
importance of Yak shaving and reward the shavers.

~~~
cortesoft
I was going to say this... every shortcut to avoid shaving a yak is just
creating a new yak that will need to be shaved next time.

Pretty soon, you are surrounded by nothing but yaks, and even yak shaving
requires shaving ten other yaks first.

~~~
quickthrower2
If you are lucky! Sometimes I reckon it’s so impossible to reason about
tangled code that the only option is to rewrite!

~~~
taneq
That's where refactoring comes in. Start with simple, local things. Make sure
all the variables are properly and consistently named. Fix the indentation.
De-duplicate cut'n'paste code (carefully!) where appropriate. Expand out
functions that are only called from one place, where appropriate. Convert
awkward control flow into more natural flow. So on and so forth. Abstract out
common functionality into its own functions/classes.

You'll be amazed how, after a few iterations of this approach, even the worst
spaghetti turns into something that you can start to reason about. (In fact, I
find myself mentally referring to this kind of refactoring as 'combing
spaghetti'.) And if you're careful to make sure none of your changes alter the
function of the code, you don't lose the 'tried-and-tested' advantage of the
original code.

~~~
rabidrat
This is peephole refactoring. Architectural redesigns (the ones that result in
1/10th the code with the same functionality but more robust, maintainable, etc
etc) aren't feasible to do incrementally like this. If you're resourceful and
clever, you can sometimes get to a certain point with both the old and the new
architecture in place at the same time, but at some point you have to make the
hard cut-over, and redevelop all the old features/edge-cases in the new
system.

~~~
taneq
Even if you're starting with a disgusting hairball, a bottom-up approach will
still get you to something understandable. At this stage you'll probably find
that you can fix it one subsystem at a time without doing a full blank-slate
rewrite. And once all of your subsystems are nice and independent and well
designed, changing up the high-level architecture is far, far easier and
safer.

------
thamer
Great example from Malcolm in the Middle:
[https://www.youtube.com/watch?v=AbSehcT19u0](https://www.youtube.com/watch?v=AbSehcT19u0)

~~~
osn9363739
I thought of that as I read the article as well!

------
bentona
I've been hearing this term probably since TFA was published, but it's only
been recently, ~15 years into my career that I realized how much I'm guilty of
this. It's so easy to get caught up in that PR for that upstream dependency so
your code is a bit prettier.

I've also noticed that the low-level yak shaving I tend towards becomes much
less tempting if I focus on decoupling what I'm writing. As long as a
function/module I'm not super happy with is nicely isolated/decoupled, who
cares? I can easily swap it out later if it becomes an issue.

------
gweinberg
I like the expression "Yak Shaving", but I don't really understand what it's
supposed to mean.

In the story, obviously the guy should return his neighbor's pillow, whether
or not he's going to immediately ask for another favor, and he probably ought
to get a new hose also. So even if he thinks shaving the yak is way too much
trouble to get his car waxed, shouldn't he shave the yak anyway?

~~~
wolfgang42
A lot of people in this thread are talking about it in the context of
technical debt, but I've always interpreted it as an allegory about time
management: you find yourself shaving a yak when you've ‘gone down the rabbit
hole’ and traversed several layers down the dependency chain of your to-do
list. When you realize this is a good time to take a moment to reflect on the
situation. Sometimes, the yak really does need shaving right now, but
sometimes it's a result of performing a depth-first search, so to speak, and
it's better to back up and take another tack, leaving the yak for later. And
even if that yak really does need shaving, taking a moment to reflect on _why_
you've found yourself shaving it can be useful to prevent frustration that the
original task doesn't even seem to have been started yet.

~~~
zeroimpl
Yeah, it seems the metaphor is about incorrectly performing a depth-first-
search, when breadth-first-search is the right algorithm in general to find
the optimal solution.

------
Pxtl
The problem is that when everybody avoids shaving the yak, the yak gets too
hairy.

"Oh, the build server can't handle that one lib, I'll just commit the DLL
directly"

"Oh that library is too confusing, I'll just roll my own for this one use-
case".

The opposite of yak-shaving is technical debt. If you find yourself in
"there's a hole in my bucket" territory, that's a sign that nobody is paying
down that technical debt ever.

There are thankless jobs in software development that basically amount to
"making sure the yak is already shaved".

------
peterwwillis
Yak shaving is _" Any seemingly pointless activity which is actually necessary
[...]"_. Yak shaving is necessary. It isn't an indicator that you _shouldn 't_
shave the yak.

Now, if you can't decide if yak shaving is necessary, ask yourself 4
questions:

    
    
      - What am I really trying to do?
      - Is this the best way to do that?
      - Is it necessary to do that?
      - Do I really need to do it right now?
    

And remember, perfect is the enemy of good.

------
smarri
I really tried to get into Seth Godin's work, blogs, books, video, the altmba.
I just find there is no substance beyond wishy washy ideas and turns of
phrase. I just read his latest blog where he tells us to look inside a box of
infinity and 'dance with it'. What am I missing here? Isn't this nonsense?

~~~
1123581321
I can speak to the blog. First, the daily posting rigor is inspiring. It makes
you want to do something useful every day.

Second, many of his blog posts prompt you to ask questions of the work you are
doing. They are not always the questions you expect and sometimes the pairing
of your current situation and the current blog post are fortuitous.

Third, he has strong, uncommonly held about how to start, continue and finish,
and find an audience for _meaningful_ work. Unless you are particularly
prolific, his writing should help you raise your expectations for yourself.

Fourth, he’s an executive and product creator and sometimes it’s worth
understanding how those people think, whether to emulate them or just to sell
to them.

That said, at this point I would start with his books because he’s had so much
time to distill his blog ideas into longer writing and it’s better to catch up
with a book than to read a lot of old posts.

------
russellbeattie
If you're yak-shaving correctly, you're laying the groundwork for future
tasks.

If you do it incorrectly, it's more like Malcolm's dad [1], who is distracted
by subtasks that are only minimally related to the initial goal.

Devs get the two mixed up quite often. Usually on Monday mornings...

1\. [https://youtu.be/AbSehcT19u0](https://youtu.be/AbSehcT19u0)

------
klyrs
> Yak Shaving is the last step of a series of steps that occurs when you find
> something you need to do. “I want to wax the car today.”

> “Oops, the hose is still broken from the winter. I’ll need to buy a new one
> at Home Depot.”

...

> So, what to do?

> Don’t go to Home Depot for the hose.

This analogy is rather awful. The takeaway I'm getting from this is "if you
hit an obstacle, stop trying." Surely that isn't what the author is trying to
tell us?

~~~
axaxs
I think you may be taking away a different than intended lesson. The
implication is that you can wash the car with a broken hose(tape it!), or with
no hose at all(buckets/pans).

~~~
klyrs
Yes, now we're getting somewhere. The fallacy is in recursively accepting the
first solution to a given problem. Rather, it's worthwhile to ruminate[1] on
multiple solutions before embarking on one that exceeds the apparent
complexity of the problem.

Digging into the analogy, though, this is a story about maintenance failures.
At some point, you're going to make good with your neighbor and also repair or
replace your hose, and it sounds like getting a pass for that bridge could
save time in the future. Waxing your car might be a vanity project. What's
most important in this moment?

[1] my first yak pun in 2020

------
IshKebab
Counterpoint: [https://github.com/flutter/flutter/wiki/Style-guide-for-
Flut...](https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-
repo#lazy-programming)

------
DonHopkins
Yak shaving is so common in the industry that I started a company renting pre-
shaved yaks, until I realized it was the fur they were after. So I pivoted,
and my new elevator pitch is: "It's like Uber for yak fur".

------
jinpan
> "And the next thing you know, you’re at the zoo, shaving a yak, all so you
> can wax your car."

I'm interpreting this as (maybe unintentionally) creating new forms of debt -
next time you want to visit the zoo, you may need to resolve some favors to
the zookeeper that let you into the yak exhibit.

------
maerF0x0
"YAGNI - You Aint Gonna Need It"[1] is a form of antidote to these kind of
meandering insanities. I often have to remind myself to do whatever it takes
to get done today, and then to return for the longterm investments _after_ if
I still think it's worth it.

In this case it probably would look like: Pay cash for the toll, get the hose,
wash the car. Consider fixing the relationship (or buy my own ezpass) _after_
the task at hand is done.

[1]:
[https://martinfowler.com/bliki/Yagni.html](https://martinfowler.com/bliki/Yagni.html)

------
wodenokoto
Does anybody know the origin of the term? The author links to [1], which says
it "probably" comes from a Ren & Stimpy episode.

According to wiktionary [2], the episode is called "Yak Shaving Day", of which
a song clip can be viewed on youtube [3] and some more googling can tell you
that yak shaving day is introduced in episode 3 of season 1.

But nothing about that song or episode has any relevance to the expression of
yak shaving. So why did the MIT lab choose that name for the expression?

[1] [http://www.catb.org/~esr/jargon/html/Y/yak-
shaving.html](http://www.catb.org/~esr/jargon/html/Y/yak-shaving.html) [2]
[https://en.wiktionary.org/wiki/yak_shaving](https://en.wiktionary.org/wiki/yak_shaving)
[3]
[https://www.youtube.com/watch?v=5mmISldi060](https://www.youtube.com/watch?v=5mmISldi060)

------
yarg
Don't shave it now, shave it later. Interfaces exist for a reason, and can
potentially provide you with a mechanism for bootstrapping new designs onto
the old base implementations.

Albeit in a less than optimal manner.

It does, however, provide you with a means to approach the eventual shaving of
the yak piecemeal.

At any step into the deep dive into madness, all you need is a viable
implementation of the highest level of required functionality.

Even if the insanity of a complete implementation can get through code review,
future archaeologists won't thank you for rebuilding existence in a single
commit.

Shave the yak if you need to, just be sure that you need to do it now.

------
big_chungus
This isn't really anything new. Sometimes, it's important to get that hose or
whatever the real-world equivalent is. The real advice is to not waste time on
things that aren't important. To poorly extend the metaphor, this is running
to home depot to buy a pack of gum. I've caught myself a few times tweaking my
i3 config or something to "increase productivity" to procrastinate something I
don't want to do. The important thing is to not do that. This advice, however,
is already well-known.

------
freehunter
It's so weird that we have a group of people who tell us don't shave the yak,
and then a group of people telling us to measure twice and cut once, and a
group of people telling us that technical debt is bad, and a group of people
telling us that we need to move fast and break things. Then you have Joel
Spolsky telling us we should never rewrite our code, but the anti yak shavers
telling us not to think too far ahead and just get the pen to the paper as
quick as possible.

But I guess you're not going to sell many books by saying "think exactly as
hard as you need to about the things you need to think about, make smart
choices, pick relevant abstractions when you can, and choose the right tool
for the job".

~~~
FPGAhacker
Most of this doesn’t seem in conflict to me.

“Don’t shave the yak.”

\- stay focused on the task at hand.

“Measure twice cut once”

\- if the output cannot be easily fixed, double check yourself before
committing.

“Technical debt is bad”

This is an oversimplification. Perhaps dangerous is a better word than bad.

“Move fast and break things”

\- a hyperbolic response to perfectionism

~~~
wayoutthere
> “Technical debt is bad” > This is an oversimplification. Perhaps dangerous
> is a better word than bad.

Technical debt is not dangerous or bad, it's just debt. It continues to
compound the longer you don't pay it down. You have to be strategic with the
resources you have, but often taking on debt is the right thing to do
(provided you intend to pay it back later).

------
perl4ever
Is this a human version of
[https://en.wikipedia.org/wiki/Priority_inversion](https://en.wikipedia.org/wiki/Priority_inversion)

------
sansnomme
This is actually part of the business justification for using SaaS/PaaS
instead of rolling your own. E.g. skip implementing auth when just starting
and simply use Firebase.

~~~
ben509
The key is to shave the yak before you're forced to.

Lots of sellers get their start on e.g. Amazon marketplace, and they find it
becomes progressively more awful as they scale up.

If they make the switch to their own site on their own schedule, this is fine.

If a competitor puts in false reviews on their product and gets them banned,
or their search rankings mysteriously plummet, the loss of revenue can
bankrupt them before they stake their own site.

------
weej
Perfection is the enemy of good enough. BUT...technical debt does factor in
when choosing the easier route that may incur longer-term problems with short
cuts.

------
yoz-y
I know nothing about waxing cars but don’t you actually need the hose?
Wouldn’t the actual solution be to get to Home Depot without the EZ pass, or
buying it instead of borrowing it.

This is to say that you should do the _necessary_ steps but no more?

~~~
other_herbert
I think the idea in the analogy would be to just use a bucket and the broken
hose as a good enough solution... Like find alternatives if the right path
ends in a yak

~~~
gwd
> Like find alternatives if the right path ends in a yak

But taking his example at face value -- I mean, you _are_ going to have to
return that pillow someday, and to return the pillow you _are_ going to have
to go to the zoo and shave the yak. I mean, yeah, today day maybe you can just
deal with the old broken hose. But if you'd shaved the yak _last_ weekend
instead of whatever other thing you were doing, you could have bought a new
hose this weekend. The longer you wait to do what you need to do anyway, the
more hassle you end up dealing with.

------
proc0
I think it works better for every day life things, because in the context of
work it amounts to making bad decisions. Building a new feature vs. fixing or
refactoring old code.

------
kristianc
I used to find this quite an appealing analysis - don’t waste time on busywork
after all. We’ve all heard that advice. I’m not sure it works in practice.

What happens if every time you go to solving one of these problems, you go
about three layers deep in your analysis rather than to the root cause.

Sometimes it isn’t a Yak to be shaved but actually something that done right,
can save you a lot of time and effort. Particularly in a field like software
development where the cost of rework is very high.

As construction friends of mine like to say, concrete erasers are expensive.

------
travbrack
I find that often times if I don't shave the Yak today, I'll end up shaving it
tomorrow. Sometimes you gotta shave that Yak.

------
dsalzman
Yak Shaving and Bike Shedding are some of my favorite sayings.

~~~
freehunter
Yak shaving sure... but bike shedding is a term I've only ever heard used to
dismiss valid criticisms without any counter argument. I've seen plenty of
projects where the simplest thing could have made all the difference, but it
was hand-waved away as "bike shedding". So the project moves ahead, ignoring
any feedback, and then people wonder why the project failed.

I've never encountered someone using the phrase "bike shedding" when it wasn't
in relation to a project that was in the middle of failing and the speaker is
looking for any excuse to ignore the real reason why. So instead they blame
everyone around them for focusing on "trivial" things. How many times was
Zune's exclusively brown color and "squirt" feature brought up and dismissed
as bike shedding? And when it was released, all the tech press could talk
about was that it looked like poop and squirted songs at you.

Details matter.

~~~
wolfgang42
I can definitely see how it could be used to steamroll over objections, but I
don't think that's a problem with the term so much as who/how it's being used.
Having a simple term in a team's shared vocabulary to point out when excessive
effort is being used on something trivial is important, because it can prevent
a lot of time from being wasted.

Here's an actual example from recently: “Hey, I think this parameter [that we
can't decide if it should be a boolean or an enum] is turning into a
bikeshed.” “Good point, leave it as a boolean for the moment and we can always
refactor later.” Something like that is not going to make or break a project,
and being able to concisely point that out is useful.

------
geocrasher
In other words:

Don't let perfection get in the way of progress.

~~~
anonytrary
But also, don't let progress get in the way of progress. Sure, over-perfecting
can get in the way of immediate progress, but under-perfecting (quick-fixes,
avoiding refactors, etc.) can get in the way of future progress. The question
of "should I refactor this or can I get away with a quick fix?" really needs
to be asked all the time. There is no silver bullet.

------
motohagiography
I told the CTO of the last startup I worked for his organization was a
bikeshed full of half shaved yaks. I hope it sunk in.

------
hydgv
(2005) in case you're confused about the "five years ago" remark

