Yak Shaving is a common problem in development teams and IT projects in general.

To understand how we fall prey to Yak Shaving, consider the following example.

John borrowed Jill’s lawnmower several weeks back, but has yet to return it. Jill calls him up and asks if she can have her lawnmower back by no later than 09h00 on Saturday as she needs to mow her own lawn in preparation for a party on the weekend.

John heads through to his garage to fetch the lawnmower. However, he decides that he should pump his car’s tyres and fill up with petrol before heading over to Jill’s house. Then he realises that he doesn’t know what pressure his car tyres should be so he calls his dealership to find out.

During his conversation with the dealership, he learns that his tyres are, in fact, the wrong size for his car so John decides to buy a new set of tyres altogether. Since the tyres are not available locally, and can’t be delivered in time, John needs to catch a train across country to purchase said tyres. However, train tickets are very expensive at this time of year. A quick internet search reveals that a return flight , with a connecting flight in Tibet, is actually cheaper than the train-fare.

Ridiculous, but true! The flight will land within spitting distance of his chosen tyre supplier and actually save him $100.

One thing leads to another…

… and pretty soon, John finds himself shaving yaks in the Himalayas — all in an effort to return Jill’s lawnmower.

A Real-World Example

This happened to a team I worked with some time back in my career.

‘The system has performance issues. Please fix it,’ came the cry from our business stakeholders.

The fix was relatively straightforward; a small flaw in the design had resulted in an implementation that failed to perform under heavy load. Since all data was flowing through a single Queue on our Message Broker, if one downstream system sneezed, the entire solution caught a cold.

The simple solution was to create multiple Message Queues and route messages to the relevant Queue based on target system. Then simply have each target system retrieve messages from its dedicated queue. Roughly a week’s work. This would solve the immediate problem — but it did not address the underlying design flaw.

So the team put their heads together and formed a think-tank. Before we know it we were discussing a complete architectural overhaul & redesigning the solution from the ground up. A solution that had three and a half years of work effort invested in it, I might add. Delivery estimate? Roughly eighteen months, and climbing.

Don’t boil the whole ocean!

When my protests went unheeded, I resigned from the think-tank and refused to attend any more meetings. I believe I left about two weeks before they began considering ways to end world hunger — by shaving yaks in the Himalayas.

Needless to say, the think-tank’s “solution” was never implemented. And the business continued to suffer with the inevitable performance issues whenever the system was under load.

Moral of the story? Focus and fix the problem on hand. Save the less pressing issues for a later date.