Don't Shave That Yak (2005) • Hacker News Board

Re: Don't Shave That Yak (2005)

#51

Post by wolfgang42 » Wed, Jan 01, 2020, 11:29 PM UTC

gweinberg wrote: post #41

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?

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.

Re: Don't Shave That Yak (2005)

#52

Post by smarri » Wed, Jan 01, 2020, 11:34 PM UTC

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?

Re: Don't Shave That Yak (2005)

#53

Post by wolfgang42 » Wed, Jan 01, 2020, 11:40 PM UTC

freehunter wrote: post #16

dsalzman wrote: post #2

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

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…

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.

Re: Don't Shave That Yak (2005)

#54

Post by closeparen » Wed, Jan 01, 2020, 11:57 PM UTC

freehunter wrote: post #21

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…

One of the hallmarks of a senior engineer is knowing how much time to spend on something. It's easy to blow past an important decision carelessly, but it's also too easy to get lost in the woods overthinking, over-documenting, setting up meetings, blocking on other teams, etc. The expert knows when to advise caution vs. when to say, "this is getting ridiculous, let's just make a choice."

Re: Don't Shave That Yak (2005)

#55

Post by taneq » Thu, Jan 02, 2020, 12:59 AM UTC

freehunter wrote: post #21

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…

> "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"

"Just be good, and don't be bad" isn't technically wrong...

Re: Don't Shave That Yak (2005)

#56

Post by tunesmith » Thu, Jan 02, 2020, 1:01 AM UTC

drewg123 wrote: post #4

" 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…

The boy scout rule is a good compromise. Whatever areas of code you touch, leave it cleaner than how you found it. It doesn't mean following every path that leads to or from it (yak-shaving), but it's also not introducing new tech debt.

Re: Don't Shave That Yak (2005)

#57

Post by taneq » Thu, Jan 02, 2020, 1:02 AM UTC

FPGAhacker wrote: post #43

freehunter wrote: post #21

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…

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

> “Don’t shave the yak.”

> - stay focused on the task at hand.

The definition of yak shaving is that shaving the yak is a prerequisite to the task at hand. You can't continue without doing it.

Of course, just because this appears to be the case doesn't always mean it's true. Plenty of times I've been waiting on X to do Y and I've managed to make significant progress on Y just by pretending that X is already done, and working on Y until X is actually necessary.

Re: Don't Shave That Yak (2005)

#58

Post by amiga_500 » Thu, Jan 02, 2020, 1:04 AM UTC

drewg123 wrote: post #4

" 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…

In medium to large size orgs "not shaving the yak" means pressing ahead with your deliverables and sidestepping wider issues. Doing this makes you appear indispensable to most middle managers but encouraging this en-masse is a long-term disaster for the org.

The org culture compels the behaviour, and is not really an individual choice.

Re: Don't Shave That Yak (2005)

#59

Post by kthejoker2 » Thu, Jan 02, 2020, 1:06 AM UTC

gweinberg wrote: post #41

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?

I've always interpreted yak shaving as "work that is neither necessary nor sufficient to complete a task."

Sometimes it's bikeshedding (looking through color swatches for your navbar when you dont even have a working CRUD system), sometimes it's indirect value add to you or your team (evaluating new ORMs or IDEs), sometimes it's just karma farming in the universe (sending PRs to a new GitHub repo you've found that almost solves your issues...)

I think of it as concentric circles: the center is the goal, the first ring is the tasks you need to complete, and so on ... and yak shaving is anything more than 2 layers away (or outside the circle entirely!)

Re: Don't Shave That Yak (2005)

#60

Post by taneq » Thu, Jan 02, 2020, 1:27 AM UTC

quickthrower2 wrote: post #18

cortesoft wrote: post #13

Earlier quoted context omitted.

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.

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

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.