Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Shave That Yak (2005)

seths.blog

Post reply on HN
Print view View original

31–40 of 87 posts

Re: Don't Shave That Yak (2005)

#31

Post by gwd »

other_herbert wrote: post #11
yoz-y wrote: 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

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

Re: Don't Shave That Yak (2005)

#32

Post by rocqua »

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…

I don't think yak shaving is the same as planning ahead. Instead, yak shaving is about putting in a bit of effort now to 'do things right' rather than quickly work around some issue.

The difference being that in planning ahead, the 'right long term thing to do' is hard to figure out. Whereas with yak-shaving, the 'right long term thing to do' is quite obvious, but the question is whether it is worth it.

Re: Don't Shave That Yak (2005)

#33

Post by axaxs »

klyrs wrote: 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).

Re: Don't Shave That Yak (2005)

#34

Post by ben509 »

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…

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

Eh, expand that out to 20,000 words and you could probably sell a few copies.

I think it'd mostly want to expand on mitigating problems that happen when you make dumb choices, can't find good abstractions or have poor tools. You're going to learn through failure, so you have to suffer through the failures.

Re: Don't Shave That Yak (2005)

#36

Post by ben509 »

sansnomme wrote: post #5

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.

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.

Re: Don't Shave That Yak (2005)

#37

Post by commandlinefan »

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…

It’s a shame we’ll likely never look forward to a time when we’re considered professionals who’ve spent decades mastering our craft and are the best qualified to determine what’s best when.

Re: Don't Shave That Yak (2005)

#38

Post by RangerScience »

jrockway wrote: post #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…

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.

Re: Don't Shave That Yak (2005)

#39

Post by michaelbuckbee »

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…

Agree 100% with what you're saying but an often unexplored dimension of this discussion is that in so many cases software solutions are so ridiculously better (more productive, less waste) than manual alternatives that it almost doesn't matter.

And fwiw - I think a book that helped walk you through the decision making process for everything would be a winner.

Post reply on HN