Live data from Hacker News

Don't Shave That Yak (2005)

seths.blog

81–87 of 87 posts

Re: Don't Shave That Yak (2005)

#81

Yak shaving is an inevitable, unavoidable part of working in a large company with mature (or rather: conservative and safe) engineering practices. A feature I’m working on right now involves a ridiculous amount of knowledge of the service component architecture and release process because making any change coordinated across two different hot services with different release schedules is absolutely hellacious. So even…

Yep. Sometimes it’s time to shut up and give that Yak and good hard shaving.

Re: Don't Shave That Yak (2005)

#82
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 was into his work at some point but got to the same point. I actually even had a little post myself, saying bye to Seth:

http://web.archive.org/web/20160818152109/http://rimantas.co...

Re: Don't Shave That Yak (2005)

#83

Earlier quoted context omitted.

> But fix the 5 sub-problems necessary to fix this the Right Way today (no matter how crazy), and at the end of the day, you will have the Right Fix in place. Plus, you'll be one step closer to solving those 25 other problems that cross through this path. Unless tomorrow you learn you need to build something completely different. This is an age old debate, and doing it technically "Right" isn't the be-all-end-all. "M…

Which side it happens to be is on entirely context-driven. If the object of "yak shaving" happens to be a mathematical proof, then the yak must be shaved. But if you have to get a system working within five minutes to stop your company losing ten million pounds, then the yak can remain unmolested.

Sometimes there's an easy way around. With the article's example, you buy an EzPass (or call the tolls-by-mail number & pay the extra fee for that vs EzPass). Then you don't need to borrow your neighbour's EzPass, or return the pillow, or restuff the pillow, or shave the yak. Likewise for many real systems, often one of the intermediate steps has a better alternative.

Re: Don't Shave That Yak (2005)

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

Look at the fruitful discussion his short blog post has created on HN. I found many comments to be very valuable here. I think that’s how his value is showing.

Re: Don't Shave That Yak (2005)

#85
Does anybody know the origin of the term? The author links to [1], which says it "probably" comes from a Ren & Stimpy episode.

According to wiktionary [2], the episode is called "Yak Shaving Day", of which a song clip can be viewed on youtube [3] and some more googling can tell you that yak shaving day is introduced in episode 3 of season 1.

But nothing about that song or episode has any relevance to the expression of yak shaving. So why did the MIT lab choose that name for the expression?

[1] http://www.catb.org/~esr/jargon/html/Y/yak-shaving.html [2] https://en.wiktionary.org/wiki/yak_shaving [3] https://www.youtube.com/watch?v=5mmISldi060

Re: Don't Shave That Yak (2005)

#86

Yak shaving is an inevitable, unavoidable part of working in a large company with mature (or rather: conservative and safe) engineering practices. A feature I’m working on right now involves a ridiculous amount of knowledge of the service component architecture and release process because making any change coordinated across two different hot services with different release schedules is absolutely hellacious. So even…

One thing I'd like to add to this.

Software Developers will often be tempted to automate the yak shaving away so they don't really have to deal with it all. This is a good attitude to have, but when combined with automation it can also be dangerous. I've seen many automated solutions run off on their own doing entirely the wrong thing. It's very often safer to slow down, build tools to assist, but have a human there to push the go button. It's not as sexy, and if you're scale is large enough you're also building tools to help with analysis. But in the long run you'll avoid problems.

Post reply on HN