Don't Shave That Yak (2005)
seths.blog
seths.blog
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.
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.
In general, you should have a cost and benefit attached to every action you are planning. Buying a hose is super easy and solves a lot of problems; you can start watering your garden again, you can wash your car, you can spray your kids. The cost is low, the benefit is high, so you should consider it today. At the bottom of the chain is "break into a zoo and shave a wild animal". The benefit is low, you can buy yak hair on Amazon. The cost is high, you're likely going to be maimed AND end up in prison. So don't do that!
This is a super dumb example and we shouldn't even be discussing it. Management consultants always have a contrived example where their advice sounds good because the example is bad. This is that.
...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.
Skip all the extra steps and just take a shortcut, and you'll fix one problem today -- and tomorrow you'll run into three consequences of this shortcut, and have to take yet more shortcuts. The next 25 problems that cross this path will be just as hard, and they'll require their own shortcuts.
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.
When solving a problem, you always get to choose whether to take on more tech debt, or pay off some existing tech debt. People almost never choose to pay off tech debt, so every step is one step closer to that inflection point where the entire project is too complex for anyone to work on, and you have to scrap it and start over.
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. "Move fast and break things" is dumb, and so is it's inverse.
Now, that doesn't mean the truth is the happy medium. It's somewhere in between, weighed to one side. I don't know which. But this is a tension, and I don't think we can afford to ignore either side.
I've seen people trying to do it exclusively by the book at all times and everything felt like a school bus in an F1 race. Yes they eventually finished but always guaranteed to be too late to be useful.
Far more rarely I've seen people trying to go the shortcut route exclusively. This has far worse results, like an F1 car trying to take kids to school. It might get there fast but sooner or later it will hit a wall. Evolution weeds out these cases a lot faster.
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 shaved, and we'd be able to work without so many distractions.
I guess the big problem with Yak Shaving, at least for a dayjob, is that it doesn't always count towards making forward progress toward your goals or OKRs, or whatever we want to call them. I think we need to recognize the importance of Yak shaving and reward the shavers.
Pretty soon, you are surrounded by nothing but yaks, and even yak shaving requires shaving ten other yaks first.
You'll be amazed how, after a few iterations of this approach, even the worst spaghetti turns into something that you can start to reason about. (In fact, I find myself mentally referring to this kind of refactoring as 'combing spaghetti'.) And if you're careful to make sure none of your changes alter the function of the code, you don't lose the 'tried-and-tested' advantage of the original code.
Do yaks not regrow their fur in this analogy?
The org culture compels the behaviour, and is not really an individual choice.
I've also noticed that the low-level yak shaving I tend towards becomes much less tempting if I focus on decoupling what I'm writing. As long as a function/module I'm not super happy with is nicely isolated/decoupled, who cares? I can easily swap it out later if it becomes an issue.
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?
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 almost solves your issues...)
I think of it as concentric circles: the center is the goal, the first ring is the tasks you need to complete, and so on ... and yak shaving is anything more than 2 layers away (or outside the circle entirely!)
Consider my example of evaluating ORMs.
Option 1: Blindly choose first ORM from a Google search.
Option 2: spend 2 hours reading reviews, blogs, etc. to compare the 3 most popular ORMs.
Option 3: spend a day spinning up containers for each ORM, testing out a CRUD prototype for each, evaluating some basic cases.
Option 4: spend a week down the deep rabbit hole of ORM internals, query rolling, edge cases at scales your app will never see ...
And everything in between. None of it's necessary - even the ORM itself - but it's not all wasted effort either.
"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".
Now, if you can't decide if yak shaving is necessary, ask yourself 4 questions:
- What am I really trying to do?
- Is this the best way to do that?
- Is it necessary to do that?
- Do I really need to do it right now?
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.
I have just read the last blog post and I believe it is about the amygdala and creative process.
"Dance with it." is probably a reference to a topic he has written in several blog posts and books. He just plants some ideas here and there. As an example, yesterday, I watched MIT OCW video "How To Speak by Patrick Winston" where he tells to repeat the subject at least 3 times. I immediately remembered this blog post: https://seths.blog/2010/12/you-will-be-misunderstood/
I agree with 1123581321's points. In addition, he always narrates his own audiobooks. The Dip is one of the first audiobooks I have listened to. He has a clear easy to understand voice.
While I can understand Seth's content may not work for everyone. It works for me. I like the man enough to regard him as a role-model so my channels are open for him(permission marketing maybe?). I also find his writing fun.
HT to Seth :)
http://web.archive.org/web/20160818152109/http://rimantas.co...
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...
> “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 the author is trying to tell us?
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
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.
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.
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
Albeit in a less than optimal manner.
It does, however, provide you with a means to approach the eventual shaving of the yak piecemeal.
At any step into the deep dive into madness, all you need is a viable implementation of the highest level of required functionality.
Even if the insanity of a complete implementation can get through code review, future archaeologists won't thank you for rebuilding existence in a single commit.
Shave the yak if you need to, just be sure that you need to do it now.
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".
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.
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.
And fwiw - I think a book that helped walk you through the decision making process for everything would be a winner.
“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 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).
> - stay focused on the task at hand.
The definition of yak shaving is that shaving the yak is a prerequisite to the task at hand. You can't continue without doing it.
Of course, just because this appears to be the case doesn't always mean it's true. Plenty of times I've been waiting on X to do Y and I've managed to make significant progress on Y just by pretending that X is already done, and working on Y until X is actually necessary.
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.
"Just be good, and don't be bad" isn't technically wrong...
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.
This is to say that you should do the necessary steps but no more?
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.
What happens if every time you go to solving one of these problems, you go about three layers deep in your analysis rather than to the root cause.
Sometimes it isn’t a Yak to be shaved but actually something that done right, can save you a lot of time and effort. Particularly in a field like software development where the cost of rework is very high.
As construction friends of mine like to say, concrete erasers are expensive.
I've never encountered someone using the phrase "bike shedding" when it wasn't in relation to a project that was in the middle of failing and the speaker is looking for any excuse to ignore the real reason why. So instead they blame everyone around them for focusing on "trivial" things. How many times was Zune's exclusively brown color and "squirt" feature brought up and dismissed as bike shedding? And when it was released, all the tech press could talk about was that it looked like poop and squirted songs at you.
Details matter.
Here's an actual example from recently: “Hey, I think this parameter [that we can't decide if it should be a boolean or an enum] is turning into a bikeshed.” “Good point, leave it as a boolean for the moment and we can always refactor later.” Something like that is not going to make or break a project, and being able to concisely point that out is useful.
Don't let perfection get in the way of progress.