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

61–70 of 87 posts

Re: Don't Shave That Yak (2005)

#61

Post by taneq »

kthejoker2 wrote: post #59
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 al…

If it's not necessary to complete the task then it's not yak shaving, it's just procrastination.

Re: Don't Shave That Yak (2005)

#62

Post by rabidrat »

taneq wrote: post #60
quickthrower2 wrote: post #18

Earlier quoted context omitted.

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

This is peephole refactoring. Architectural redesigns (the ones that result in 1/10th the code with the same functionality but more robust, maintainable, etc etc) aren't feasible to do incrementally like this. If you're resourceful and clever, you can sometimes get to a certain point with both the old and the new architecture in place at the same time, but at some point you have to make the hard cut-over, and redevelop all the old features/edge-cases in the new system.

Re: Don't Shave That Yak (2005)

#63

Post by 1123581321 »

smarri wrote: post #52

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?

I can speak to the blog. First, the daily posting rigor is inspiring. It makes you want to do something useful every day.

Second, many of his blog posts prompt you to ask questions of the work you are doing. They are not always the questions you expect and sometimes the pairing of your current situation and the current blog post are fortuitous.

Third, he has strong, uncommonly held about how to start, continue and finish, and find an audience for meaningful work. Unless you are particularly prolific, his writing should help you raise your expectations for yourself.

Fourth, he’s an executive and product creator and sometimes it’s worth understanding how those people think, whether to emulate them or just to sell to them.

That said, at this point I would start with his books because he’s had so much time to distill his blog ideas into longer writing and it’s better to catch up with a book than to read a lot of old posts.

Re: Don't Shave That Yak (2005)

#64

Post by taneq »

rabidrat wrote: post #62
taneq wrote: post #60

Earlier quoted context omitted.

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

This is peephole refactoring. Architectural redesigns (the ones that result in 1/10th the code with the same functionality but more robust, maintainable, etc etc) aren't feasible to do incrementally like this. If you're resourceful and clever, you can sometimes get to a certain point with both the old and the new architecture in place at the same time, but at some point you have to make the hard cut-over, and redevel…

Even if you're starting with a disgusting hairball, a bottom-up approach will still get you to something understandable. At this stage you'll probably find that you can fix it one subsystem at a time without doing a full blank-slate rewrite. And once all of your subsystems are nice and independent and well designed, changing up the high-level architecture is far, far easier and safer.

Re: Don't Shave That Yak (2005)

#65

Post by DonHopkins »

Yak shaving is so common in the industry that I started a company renting pre-shaved yaks, until I realized it was the fur they were after. So I pivoted, and my new elevator pitch is: "It's like Uber for yak fur".

Re: Don't Shave That Yak (2005)

#69

Post by maerF0x0 »

"YAGNI - You Aint Gonna Need It"[1] is a form of antidote to these kind of meandering insanities. I often have to remind myself to do whatever it takes to get done today, and then to return for the longterm investments _after_ if I still think it's worth it.

In this case it probably would look like: Pay cash for the toll, get the hose, wash the car. Consider fixing the relationship (or buy my own ezpass) _after_ the task at hand is done.

[1]: https://martinfowler.com/bliki/Yagni.html

Re: Don't Shave That Yak (2005)

#70

Post by zeroimpl »

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

Yeah, it seems the metaphor is about incorrectly performing a depth-first-search, when breadth-first-search is the right algorithm in general to find the optimal solution.
Post reply on HN