Don't Shave That Yak (2005) • Hacker News Board

Re: Don't Shave That Yak (2005)

#21

Post by freehunter » Wed, Jan 01, 2020, 9:14 PM UTC

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 and just get the pen to the paper as quick as possible.

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

Re: Don't Shave That Yak (2005)

#22

Post by Waterluvian » Wed, Jan 01, 2020, 9:16 PM UTC

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…

That's the thing I'm discovering with recent new management. They've always got a clever sounding one liner to back up their directive. But a lot of the time it leaves me less convinced that their directive is the correct one because it doesn't actually reveal anything new about the issue.

Re: Don't Shave That Yak (2005)

#23

Post by opportune » Wed, Jan 01, 2020, 9:19 PM UTC

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 though customers will barely notice the change, I have to do all this release and flag and migration and analysis work simply because people actually use and depend on our service and we have to be really careful not to break it.

It’s not necessarily a bad thing. If we didn’t have to yak shave, it would mean we either weren’t making money, didn’t care about our customers, or didn’t do anything important. In 2005, maybe most people weren’t working on hot services with complex architectures that people depended on. But imagine what would happen if the tens of thousands of people working on AWS all collectively decided to not shave yaks when they updated their services.

On an individual basis, your decision to not shave a yak might save time and effort. At scale, it increases your error rate. If you have thousands of developers and hundreds of components/services to keep track of, issues are already an inevitability, and you’re increasing the rate at which issues would occur by a lot.

Re: Don't Shave That Yak (2005)

#24

Post by [deleted] » Wed, Jan 01, 2020, 9:20 PM UTC

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?

[deleted]

Re: Don't Shave That Yak (2005)

#25

Post by [deleted] » Wed, Jan 01, 2020, 9:27 PM UTC

cortesoft wrote: post #13

drewg123 wrote: 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.

[deleted]

Re: Don't Shave That Yak (2005)

#26

Post by lainga » Wed, Jan 01, 2020, 9:27 PM UTC

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…

Hey, you could make a book out of that idea.

Re: Don't Shave That Yak (2005)

#27

Post by russellbeattie » Wed, Jan 01, 2020, 9:29 PM UTC

If you're yak-shaving correctly, you're laying the groundwork for future tasks.

If you do it incorrectly, it's more like Malcolm's dad [1], who is distracted by subtasks that are only minimally related to the initial goal.

Devs get the two mixed up quite often. Usually on Monday mornings...

1. https://youtu.be/AbSehcT19u0

Re: Don't Shave That Yak (2005)

#28

Post by aqme28 » Wed, Jan 01, 2020, 9:30 PM UTC

drewg123 wrote: 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…

In my experience, only doing it "perfectly" means it'll never get done.

Re: Don't Shave That Yak (2005)

#29

Post by Pxtl » Wed, Jan 01, 2020, 9:34 PM UTC

The problem is that when everybody avoids shaving the yak, the yak gets too hairy.

"Oh, the build server can't handle that one lib, I'll just commit the DLL directly"

"Oh that library is too confusing, I'll just roll my own for this one use-case".

The opposite of yak-shaving is technical debt. If you find yourself in "there's a hole in my bucket" territory, that's a sign that nobody is paying down that technical debt ever.

There are thankless jobs in software development that basically amount to "making sure the yak is already shaved".

Re: Don't Shave That Yak (2005)

#30

Post by itronitron » Wed, Jan 01, 2020, 9:41 PM UTC

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…

clearly someone needs to containerize the yak, then it would be easy to both shave and wax it.