
Yak shaving and fixing - skellertor
https://sophiebits.com/2018/12/03/yak-shaving-fixing.html
======
Deestan
Agree with the main point: _Do_ regularly step outside "your" assigned work to
fix problems.

I still think yak shaving is bad, but tautologically. It's only called yak
shaving when you go too deep.

Not yak A: My build failed with no sensible error given, so I improved the
build process to log errors better.

Not yak B: My build failed with no sensible error given, so I had to log into
the build server to inspect it, so I had to run around asking people how to
get remote desktop credentials. I then documented on the internal Wiki how and
where to find credentials, and improved the build process to log errors
better.

Yak territory: In scenario B, I found the remote desktop software is running
an old version, so I set out to update it on the build server.

Deep Yak territory: While updating the remote desktop software, I realized
that it would be good to update it on all build servers, so I make a script to
do that. Such a script should also run automatically to upgrade to a newer
version when it becomes available so I don't have to manually to this every
time. I could run the script on the build master, but the script is in Python
3, and the build master only has Python 2 installed. Installing Python 3 I
notice I need to keep Python 2 the default to not mess with execution of
existing scripts. But the existing scripts are mostly thin layers above Python
libraries that exist in Python 3, so it wouldn't be a big task to port them
over and thus simplify everything.

~~~
crispyambulance
The things you cite as "Yak territory" are just bad, anti-productive
decisions.

Yak shaving, by definition, is a seemingly unrelated problem that _needs_ to
be solved before progressing with the primary task. In other words, if it's
merely an optional decision, it's not really "Yak shaving".

The only way you avoid Yak shaving is by an uncanny combination of careful
planning and organizational flexibility. Sometimes Yak shaving can't be
avoided, that's OK, it's a learning experience and it builds skills, character
and funny stories.

~~~
peteretep
> Yak shaving, by definition

Depends whose definition you choose to use. The apparent primary source[0]
doesn't have it as a dependency, the later jargon file does[1], and then there
are seem to be an approximate equal split of others.

[0] [https://projects.csail.mit.edu/gsb/old-archive/gsb-
archive/g...](https://projects.csail.mit.edu/gsb/old-archive/gsb-
archive/gsb2000-02-11.html)

[1] [http://catb.org/jargon/html/Y/yak-
shaving.html](http://catb.org/jargon/html/Y/yak-shaving.html)

~~~
setr
My internal definition is something close to "7-steps removed"; yak-shaving is
yak-shaving when you end up pretty far from the problem itself; whether its
actually good or required is independent, just the fact that it might be time
to start wondering if you went on too many tangents.

Eg quintessential example of knuth -- everything he did was good work, and in
the end useful for his overarching goals... but at some point in the middle of
that situation its time to start wondering if he's gone off the deep end.
Whether you decide yes or no, it doesn't matter, you're still deep in yak
territory

------
zby
The fact that that Seth Godins blog post that denigrates 'yak shaving' comes
so prominent on web search for the term is really too bad - but he is not even
a programmer! I believe that any healthy programmers culture supports yak
shaving. The metaphor is an expression of how frustrating is to do the right
thing, but it would not be a virtue if it was easy.

Yak shaving is the only sane way to maintain a big codebase. The more popular
thing, and the root of all evil, is to add work arounds that mask the real
problem instead of finding the right place for it somewhere deep down in the
code. It is like: you discover a bug in a library that you use and instead of
fixing it and sending patches to the author you just add a special case to
deal with it. The result is that the code gets more and more irregular with
special cases everywhere.

~~~
jonathantm
Indeed. If you don't shave your yak when you should, your yak(s?) will shed
profusely and the hair will clog not only your shower, but also all the
plumbing in your house. Thus, creating a kind of "kuldge debt".

------
alasdair_
Organizational culture matters here. There is little benefit to fixing things
if you have a culture where speed matters above everything else and people are
rewarded on how quickly they can do things.

I still remember the time I spent weeks working with a giant mess of
undocumented (or, worse, documented incorrectly) code to get my job done as
the first engineer at a startup. We had a new hire coming (and lots more
coming after that), so I took the time to clean everything up and document all
the fixes, then trained the person instead of leaving them to figure it all
out. Result: they got up and running within a few days instead of a couple of
weeks.

Of course, when review time came, I was told that the new hire had gotten up
to speed much faster than I did, which was why they were being promoted over
me...

~~~
milesvp
Ouch. I learned that this was a management anti-pattern when I was younger
from fiction of all places. I loved reading Piers Anthony, and I think it was
in his Apprentice Adept series, there was a series of tests that a person had
to take to become a citizen, and some of them were competitive. Of course, at
one point the main character made the mistake of giving pointers to a
competitor, and the competitor only got better as a result when they played a
duet. It blew my mind as a teenager when the main character won the
competition _because his opponent played better_ when the two of them played
together. It was such a foreign concept to me, that someone could act as a
sort of force multiplier, and also be rewarded for it. After that, I don't
think I ever hesitated to help bring people up. Even in college when grading
curves meant others doing better could only hurt me, I'd still often try to
explain things to people before a test.

It's a shame how many people never learned this lesson. Or maybe it's just a
testament to how many bad managers there are that these are common things
people get passed over for. Though, truthfully, if I were a manager, I'm a
little afraid that I'd still be susceptible to this bias as well.

------
quickthrower2
I don't see fixing the tools everyone in the team is using as you go along as
yak shaving. That's just good manners.

~~~
crispyambulance
Well, yeah, up to a point.

But if the fixing process ends up being the equivalent in cost, time and
resources as putting together an expedition lead by your favorite project
manager to fly to Kabul Afghanistan and then find a Yak and shave it-- that's
more like the type of disruption that "Yak Shaving" refers to. It's not just a
few quick edits.

I've always wondered, how much would it take for a good team of workers to
leave their cubicles and literally shave a Yak?

------
saagarjha
> To be able to fix effectively, you gotta be willing to dive into code that
> you didn’t write. And into lower layers of the stack than you might be used
> to.

Honestly, this is usually why I like to fix bugs in tools too. This, and
because I don't like there being bugs in things I rely on.

------
z3t4
I always seem to find these issues when I'm in a hurry. They always show up
when things are on fire. And they seem to have magically disappeared/unable to
repeat, or are no longer an prioritized issue - when you have time to fix
them.

------
gwking
I just happened to be reflecting on the term "yak shaving" this morning. I saw
Free Solo last week, and was motivated (by the funny scene of Honnold and
Caldwell in the little hotel room) to start keeping a programming journal.
Writing in it this morning I realized that my efforts yesterday were a classic
shave: I forked a library, started converting the tests to my own testing
framework, updated a terminal coloring module that the test harness to uses,
then added an interactive mode to update failing test expectations on the
command line (which I've been wanting for ages), which enticed me to port some
old termcap code I had to enter `cbreak` mode gracefully for one-touch `y/N`
interactions (totally optional but made it feel good).

I appreciate Deestan's comment: "It's only called yak shaving when you go too
deep." However I personally find the term to be more subtle than a blanket
pejorative. To me, the experience is of working with a big mental stack of
contexts, where I spend the day toiling on various far-removed dependencies in
an effort to achieve some goal _well_ (whatever "well" means that day). In
this light, it's not that yak shaving is bad, but that there is some aspect of
personal pride, and that it is hard to do without getting lost, working on
things that end up not mattering, or losing momentum and motivation.

My efforts yesterday feel worthwhile. The detours I took succeeded, and
yielded results that I have long desired. Other times I'm not so satisfied.
Knowing when to start shaving seems to be an intuitive choice, because the
payoff is too disparate and subtle to be calculated.

(There was an article on HN a while ago calling Knuth the patron saint of yak
shaving, which I enjoyed, and which gave me the ideas that a) the term has
something to do with pride in quality, and b) maybe it should not be used in a
judgmental way. I also recall my late colleague James Golick, whom I miss
dearly, using the term, with varying implications, to describe our daily work
of untangling a web/mobile app that we inherited as contractors.)

------
coldcode
I work in a place filled with broken yaks where only new projects have
privilege and everything else is denigrated as maintenance and often shuffled
to outsourced teams. Only when a yak causes major customer complaints does it
get "shaved". There is no encouragement or reward in fixing things that are
broken or to avoid them breaking eventually. Maybe we as technologists only
like new and exciting things and keeping older (not necessarily all that old)
things working well is considered beneath us.

------
gwern
I think it's helpful to split 'yak shaving' scenarios into 3 kinds, of which
only 1 implies you should shave yaks as you encounter them:
[https://www.lesswrong.com/posts/nbiZc7KM2KEyCAaCP/in-
support...](https://www.lesswrong.com/posts/nbiZc7KM2KEyCAaCP/in-support-of-
yak-shaving)

------
jspash
I don't look at Yak shaving any differently than a normal feature/bug
workflow. If something crops up during development or fire-fighting I will
make a note and continue on with what I was doing.

Later, the notes get written up into proper bug reports during the time I've
set aside for this type of work.

These are added to the normal pipeline and prioritised the same as any other
feature or bug. Important tasks rise to the top. Others are reserved for
"cleanup sprints".

This does add some overhead but it means all tasks get careful consideration.

It also gives us a great list of short tickets to do on a Friday afternoon.
Since these kinds of tasks usually don't need the kind of focus that normal
development does.

------
hnruss
On fixing bugs, the author writes: “...there is always a logical explanation
for why a computer is behaving in a certain way...”

I agree. Determining the logical explanation for why a bug exists is required
in order to fix a bug correctly. Any fix made without doing so is pure
conjecture. That said, it can sometimes be acceptable to write a fix based on
conjecture, but it should at least be documented as such.

------
vinceguidry
When things are sane, I'll generally add a few hours to a day or so to each
ticket to spend on improving process, refactoring, or just deep thinking about
the domain and the stack. Nobody notices and the effort improves everything I
do in the future.

------
AstroJetson
I use this chart from XKCD [https://xkcd.com/1205/](https://xkcd.com/1205/) to
decide how much time to spend on something. Sometimes you need to do something
that takes longer if there is a broken process that is only going to get
worse.

I'm like the author, I do fix things as I find them, but only if there is test
cases to run afterwards. I'm unlikely to mess with something if it's not fully
hooked into our test environment.

