Live data from Hacker News

Don't Shave That Yak (2005)

seths.blog

11–20 of 87 posts

Re: Don't Shave That Yak (2005)

#11
post #8

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?

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

Re: Don't Shave That Yak (2005)

#12
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.

Re: Don't Shave That Yak (2005)

#13
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…

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.

Re: Don't Shave That Yak (2005)

#15
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.

Re: Don't Shave That Yak (2005)

#16
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 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.

Re: Don't Shave That Yak (2005)

#18
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…

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!

Re: Don't Shave That Yak (2005)

#19
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.

Re: Don't Shave That Yak (2005)

#20

In other words: Don't let perfection get in the way of progress.

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.
Post reply on HN