Yak-Shaving and Bikeshedding
Engineering Insights
In this essay, I want to introduce you to a couple of useful engineering terms: Yak-shaving and Bikeshedding. They describe activities that will probably seem familiar, although you may not have heard them referred to by these names.
Yak-Shaving
“Shaving a Yak” means performing a seemingly endless series of small tasks that must be completed before the next step in the project can move forward.
For example, let’s say you want to drive to the store to pick up some groceries, and you notice that your car has a flat tire. So you decide to put some air in the tire, only you remember that you lent your tire pump to your neighbor. So now you have to go to your neighbor’s house and ask them for the tire pump back. Only, there’s a problem: last week your 5-year-old daughter ruined one of the neighbor’s couch cushions, and you promised you’d replace it, so now you feel guilty about asking the neighbor for the tire pump when you haven’t fulfilled your promise. Unfortunately, the couch cushions were stuffed with genuine Tibetan yak fur, so now you end up having to shave a yak…
Although this is a silly story (see the original story here), it is characteristic of the kinds of nested task dependencies often found in a large engineering project. It may seem like you are spending a lot of time working on things that have nothing to do with your overarching goal.
Yak-shaving is a value-neutral term: if the small tasks are really required, then it’s a good thing; but if they are not, then it’s not. In the story given above, it’s not actually necessary to shave the Yak in order to get to the grocery store; what’s really happening is the protagonist is making life difficult for themselves as a strategy for avoiding what they believe to be an emotionally difficult interaction with the neighbor. Similar scenarios happen in software projects fairly often.
Bikeshedding
The term “bikeshedding” refers to the tendency for a committee to spend time discussing the most trivial and easily-understood aspects of a design, rather than focusing on the important fundamentals.
The story goes like this: a board of directors is deciding on whether to fund construction of an atomic power plant. All of the blueprints and technical specifications are laid out in front of them. But instead of discussing complex issues such as coolant flow rates or electricity pricing forecasts, they spend an hour deciding what color the bike shed should be painted.
Most of the time, “bikeshedding” is a perjorative: it means that people are wasting time discussing trivial matters. This pattern of behavior is relatively common in engineering projects.
However, I’ve also seen the term used ironically, as a positive. Such as, “Here’s my latest design for the REST API, feel free to bikeshed on the query parameter names.” In this instance, the author is inviting reviewers to nitpick on the small syntactical details of their proposal.
There’s a time and a place for focusing on small details, and there are other times when the focus should be on the big picture.
