Yak scratching

Recently when reading Thoughtworks blogs I coined the “yak-shaving” term. It means “any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you’re working on”. There is also an interpretation such as “doing it well now is much better than doing it perfectly later”, but I like the first one better.

As one can expect from working in a big company on “legacy system” it allows you to experience a lot of yak-shaving activities. For example, you want to catch breakpoint to understand a piece of code or make sure you change actually works (ask me why you cannot.. don’t write unit test). To catch breakpoint you would need database server on other continent, several feeds and services to be up (they can occasionally be down) and probably a remote desktop connection to market emulator which is shared by a whole bunch of people.

After reading about yak-shaving I retold the story to several co-workers. Some of them didn’t get it, some (those who know the pain of yak-shaving) enjoyed it, but best of all I liked one response. I told a guy the yak-story, he spent about half-an-hour trying to get a breakpoint according to the above “methodology” and then exclaimed ”I’m scratching the yak”. This, I believe, is more precise description of what we sometimes do. You’re not just shaving it, but scratching. You may know with some degree of certainty how to get to the actual problem, but obstacles you face are so uncertain, unrepeatable and numerous, that despite all efforts you get nowhere and the only thing you left with is misery and despair. Indeed “shaving” sounds to optimistic in this case. “Shaving” assumes you’re making progress. But when you stuck with some totally unrelated problem for hours and then you get another one and then another, “scratching the yak” seems much more appropriate term.

Does it have to be this way? Why do we do yak-scratching? (I won’t go into five why’s.) What can we do about it? May be it’s our incompetence and lack of knowledge? May be it’s the way big systems are developed? Or may be it’s yaks’ conspiracy? From technical point of view we could separate system into modules with clear contracts. Develop modules separately. Create fakes for external systems and write automated tests. Sounds good but it requires political will. You have to convince management it will pay off for business. You have to convince people who work on project it won’t change one yak to another. Not to mention you have to be sure you’re right. (I realize it can be self-deception and blaming others is not a solution anyway.)

Not all technical problems are really technical. Beware of yaks.