Don't Shave That Yak (2005)(seths.blog)
seths.blog
Don't Shave That Yak (2005)
https://seths.blog/2005/03/dont_shave_that/
86 comments
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.
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.
Yep. Sometimes it’s time to shut up and give that Yak and good hard shaving.
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 your car, and continue to ignore your neighbor whose pillow you ignored.
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.
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.
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.
...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.
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.
Having tried both ways, I have the opposite view.
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.
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.
> 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. "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.
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.
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.
I guess the "art" lies in quickly identifying where you can take the shortcut and where you shouldn't. The best way to see this is to look at a competitive environment where most people are just as qualified at achieving the result whether by the book or by cutting the occasional corner. You'll notice that what sets apart the best is that they seem to know exactly when to use each method. It's like a rally, some corners you can cut, some you can't. Knowing which is which will save you precious seconds.
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.
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.
"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 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.
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.
The boy scout rule is a good compromise. Whatever areas of code you touch, leave it cleaner than how you found it. It doesn't mean following every path that leads to or from it (yak-shaving), but it's also not introducing new tech debt.
To be honest, most discussions about anti-Yak Shaving are about willfully ignoring the fact that you're going to have to shave a Yak, then asking people to strategically pluck single hairs whenever they're walking past the Yak because razors are expensive.
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.
Pretty soon, you are surrounded by nothing but yaks, and even yak shaving requires shaving ten other yaks first.
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 functions/classes.
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.
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.
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.
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.
[deleted]
> 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.
Do yaks not regrow their fur in this analogy?
Do yaks not regrow their fur in this analogy?
In medium to large size orgs "not shaving the yak" means pressing ahead with your deliverables and sidestepping wider issues. Doing this makes you appear indispensable to most middle managers but encouraging this en-masse is a long-term disaster for the org.
The org culture compels the behaviour, and is not really an individual choice.
The org culture compels the behaviour, and is not really an individual choice.
In my experience, only doing it "perfectly" means it'll never get done.
Great example from Malcolm in the Middle: https://www.youtube.com/watch?v=AbSehcT19u0
I thought of that as I read the article as well!
I've been hearing this term probably since TFA was published, but it's only been recently, ~15 years into my career that I realized how much I'm guilty of this. It's so easy to get caught up in that PR for that upstream dependency so your code is a bit prettier.
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.
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.
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?
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 shaving right now, but sometimes it's a result of performing a depth-first search, so to speak, and it's better to back up and take another tack, leaving the yak for later. And even if that yak really does need shaving, taking a moment to reflect on why you've found yourself shaving it can be useful to prevent frustration that the original task doesn't even seem to have been started yet.
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.
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 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!)
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!)
If it's not necessary to complete the task then it's not yak shaving, it's just procrastination.
Well, sure, procrastination is a subset of yak shaving ... but it's also a matter of degree.
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.
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.
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".
"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".
Yak shaving is "Any seemingly pointless activity which is actually necessary [...]". Yak shaving is necessary. It isn't an indicator that you shouldn't shave the yak.
Now, if you can't decide if yak shaving is necessary, ask yourself 4 questions:
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?
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.
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.
For me, Seth Godin is about defining a vocabulary around being a productive and decent human-being and thinking about your approach and psychology. I think the ideas help the reader to navigate in this complex world without having a cynical worldview.
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 :)
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 :)
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...
http://web.archive.org/web/20160818152109/http://rimantas.co...
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.
I think the exercise of {clarifying why it is nonsense} has value.
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
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
> 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 the author is trying to tell us?
> “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?
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).
Yes, now we're getting somewhere. The fallacy is in recursively accepting the first solution to a given problem. Rather, it's worthwhile to ruminate[1] on multiple solutions before embarking on one that exceeds the apparent complexity of the problem.
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
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
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".
> "And the next thing you know, you’re at the zoo, shaving a yak, all so you can wax your car."
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.
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.
"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
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
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
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
Don't shave it now, shave it later.
Interfaces exist for a reason, and can potentially provide you with a mechanism for bootstrapping new designs onto the old base implementations.
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.
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.
[deleted]
This isn't really anything new. Sometimes, it's important to get that hose or whatever the real-world equivalent is. The real advice is to not waste time on things that aren't important. To poorly extend the metaphor, this is running to home depot to buy a pack of gum. I've caught myself a few times tweaking my i3 config or something to "increase productivity" to procrastinate something I don't want to do. The important thing is to not do that. This advice, however, is already well-known.
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".
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".
One of the hallmarks of a senior engineer is knowing how much time to spend on something. It's easy to blow past an important decision carelessly, but it's also too easy to get lost in the woods overthinking, over-documenting, setting up meetings, blocking on other teams, etc. The expert knows when to advise caution vs. when to say, "this is getting ridiculous, let's just make a choice."
Most of this doesn’t seem in conflict to me.
“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
“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 bad”
> This is an oversimplification. Perhaps dangerous is a better word than bad.
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).
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).
> “Don’t shave the yak.”
> - 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.
> - 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.
> 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.
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.
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.
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.
And fwiw - I think a book that helped walk you through the decision making process for everything would be a winner.
> "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"
"Just be good, and don't be bad" isn't technically wrong...
"Just be good, and don't be bad" isn't technically wrong...
> 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".
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.
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.
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.
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.
Hey, you could make a book out of that idea.
clearly someone needs to containerize the yak, then it would be easy to both shave and wax it.
Is this a human version of
https://en.wikipedia.org/wiki/Priority_inversion
[deleted]
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.
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.
Except that usually just leads to shaving a vendor-painted yak.
Perfection is the enemy of good enough. BUT...technical debt does factor in when choosing the easier route that may incur longer-term problems with short cuts.
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?
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.
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.
[deleted]
I think it works better for every day life things, because in the context of work it amounts to making bad decisions. Building a new feature vs. fixing or refactoring old code.
I used to find this quite an appealing analysis - don’t waste time on busywork after all. We’ve all heard that advice. I’m not sure it works in practice.
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.
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 find that often times if I don't shave the Yak today, I'll end up shaving it tomorrow. Sometimes you gotta shave that Yak.
Yak Shaving and Bike Shedding are some of my favorite sayings.
Yak shaving sure... but bike shedding is a term I've only ever heard used to dismiss valid criticisms without any counter argument. I've seen plenty of projects where the simplest thing could have made all the difference, but it was hand-waved away as "bike shedding". So the project moves ahead, ignoring any feedback, and then people wonder why the project failed.
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.
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.
I can definitely see how it could be used to steamroll over objections, but I don't think that's a problem with the term so much as who/how it's being used. Having a simple term in a team's shared vocabulary to point out when excessive effort is being used on something trivial is important, because it can prevent a lot of time from being wasted.
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.
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.
In other words:
Don't let perfection get in the way of progress.
Don't let perfection get in the way of progress.
But also, don't let progress get in the way of progress. Sure, over-perfecting can get in the way of immediate progress, but under-perfecting (quick-fixes, avoiding refactors, etc.) can get in the way of future progress. The question of "should I refactor this or can I get away with a quick fix?" really needs to be asked all the time. There is no silver bullet.
I told the CTO of the last startup I worked for his organization was a bikeshed full of half shaved yaks. I hope it sunk in.
[deleted]
(2005) in case you're confused about the "five years ago" remark
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.