Live data from Hacker News

Don't Shave That Yak (2005)

seths.blog

41–50 of 87 posts

Re: Don't Shave That Yak (2005)

#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?

Re: Don't Shave That Yak (2005)

#42
post #33
post #10

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

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).

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

Re: Don't Shave That Yak (2005)

#43

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

Re: Don't Shave That Yak (2005)

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

To be honest, most discussions about anti-Yak Shaving are about willfully ignoring the fact that you're going to have to shave a Yak, then asking people to strategically pluck single hairs whenever they're walking past the Yak because razors are expensive.

Re: Don't Shave That Yak (2005)

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

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

Do yaks not regrow their fur in this analogy?

Re: Don't Shave That Yak (2005)

#46

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

> “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).

Re: Don't Shave That Yak (2005)

#47
> "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.

Re: Don't Shave That Yak (2005)

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

Re: Don't Shave That Yak (2005)

#49

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…

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

You're right. That's exactly what needs to be done but it will NEVER be perfect. There's always going to be some Yak shaving in all but the most pedestrian of projects.

Project managers might call it "unplanned work". They know it happens. Savvy ones accept it to some extent and realize that's a important part of how people build grit, experience and good judgement-- sometimes it takes a few hard knocks.

Post reply on HN