Shaving Yaks

 

Shaving Yaks

Oh boy, if you’re not familiar with the term, you’re gonna love this.

‘Yak Shaving’ is a term coined by Carlin Vieri at MIT in late 90s. Basically it means doing something that looks like it has no relevance whatsoever to the actual task at hand. The more steps between the two - the better. I’ll give you an example.

You’re on your day off, walking around the countryside and witness the most beautiful view ever. You’re a hobby photographer, so you decide that it would be great if you took a picture of it. You realize that you left your super-expensive camera at work. So you go to your car and start driving to work. While on your way, it hits you - you don’t have the keys to the office, you’ve left them at your vacation house in a different city. You think to yourself: ‘ok, who else has keys, knows me and doesn’t live too far away?’. You remember Jamie - he’s your work colleague, he lives nearby and has keys. So you turn your car and start driving to Jamie. On your way you realize that Jamie probably won’t lend you the keys, because you still haven’t returned that stuffed panda you borrowed from him last time because of reasons (your kid liked it and refused to go home without it). So you turn your car again and drive home to collect the panda. And suddenly it clicks, you didn’t return the panda, because your dogs decided to go on a rampage, tore a hole in the toy and you ended up with panda stuffing all over your place; after cleaning it up - half of it was too dirty to put back in. And it was some fancy yak hair too. So before you know it - it’s getting dark, you’re in a zoo, shaving a yak to take a photo of the view you liked ten hours ago.

It happens pretty frequently in software engineering, but I think that shaving a yak isn’t necessarily a bad thing. It depends. Let me explain.

The Good

Suppose you need to add a feature to an existing piece of software. Through the magic of debugging you find the class into which the new stuff should go. Brilliant, the problem, though, is that this class is 10,000 lines of code long. The variables are strangely named, some code is commented out, there’s at least five inner classes, a few chunks of dead code. So you spend a while giving variables descriptive names, getting rid of commented out and dead code (because in the age of source control why have it?). Split some of the existing functionality into smaller specialised external classes, re-arrange the methods into the order they are being called in within each class and then, finally, add the new functionality. It might look like a waste of time that could’ve been spent on something more useful, like adding the new functionality, but it really isn’t. In the process of shaving this yak you:

1) Get a better understanding of how everything is connected; 2) Save the time of the next person who’ll have to work with this class; 3) Reduce technical debt; 4) Make that functionality more testable; 5) Come out of the whole process being a tiny bit more confident that your solution does what it’s supposed to.

Of course in the real world there’s frequently not enough time for code spring-cleaning. But you can always do it iteratively. Rather than shave the yak completely in one go - shave bits of it instead. Although, if you wait long enough - the hair will grow back (code decay) and you’ll have to start over again. I’m really nailing this analogy!

The Bad

It is way too easy to focus on a single way of doing things without considering any alternatives. Very rarely does a software puzzle have only one solution, it might well be the case that one of them requires jumping through hoops, investigating, trying, failing, trying again and the other does not. Sometimes you just need to step back mid-way through the process and figure out whether the outcome is worth the effort, frequently it isn’t. So you go back to square one and try a different route. I find that for me a great approach to avoid getting hung up on that one way of solving the problem is to talk to my colleagues. They can be more experienced with the code, with the programming language or have a better understanding of the functionality that you’re trying to implement. Daily scrums are great for that.

The Ugly

In some companies it’s just a valid part of the process. Consider a customer getting in touch with support about a bug. A ticket for that bug gets created and assigned to you. You need to reproduce the bug, so you find the right versions of the products that you need to install in order to accurately reproduce the client’s issue. It is known that sometimes wrong installation settings cause the setup to break, so your company encourages reproducing the customer environment on a virtual machine that lives on a remote server. That way you can take snapshots of the system and roll-back to them without losing much progress. Better security too. In order to get the virtual machine that matches your required specifications you need to both have the correct grants and raise a ticket to get a machine assigned to you.

Once you do get the correct grants and a virtual machine, you install the needed software, maybe it doesn’t break on the first try, so you only do that once. You then open the product that the client had an issue with, try to reproduce the bug - and everything works fine, it never breaks. So, because you don’t have direct contact with the client, you get in touch with a support person and explain the problem. They arrange a conference call between the three of you. Finally, you figure out all the steps the client took to get the error. You reproduce them on the virtual machine and see the bug. Time to get fixing.

You find that you need the correct access rights to get the code for that specific version of the product that the client is having issues with. So you raise a ticket and wait.

Once you get the rights, you get the code and start fixing. The process between the that first customer call and you fixing the code can take weeks. But you’re finally there. You create a fix, you get it to the customer, you push it into the closest release for that version of the product and you’re done, right? Well, it heavily depends on whether the different versions of the product count as different products, because if they do - it’s back to virtual machines and reproducing the bug on every version of it that’s still supported. Best case scenario - the bug is already fixed in later versions, worst case scenario - it isn’t and a simple copy/paste of fixed code won’t do the trick.

I suppose the bigger the company - the more bureaucratic it is, the more bureaucratic it is - the more you get to shave yaks. It’s almost inevitable.

To Sum Up

‘Yak shaving’ is a fun term. The process behind it is sometimes good, sometimes bad, sometimes it’s a necessity. And it definitely makes morning scrums a lot more fun when someone starts their status with a: ‘well, yesterday evening I was still shaving my yak’.

The post was inspired by these two pages: one by Scott Hanselman, the other from RationalWiki.