You can side-step a yak, they don't all need to be shaved

Last week we said that yak shaving gets in the way of making steady progress. A reader wrote in to pick a bone with my definition.

I said that yak shaving trends towards procrastination. You're moving things around and making unnecessary improvements because you're not sure how to move forward on your main goal.

The reader, who did not leave a name, had this to say:

👎 Actually I like it, as usual. But wanted to get your attn, and pick one nit: "Yak shaving" is usually something you HAVE to do in order to do the thing (needed to do the thing... * N) closer to your goal.

Did Donald Knuth, patron saint of yak shaves, really need to invent TeX to make progress in his legendary The Art of Computer Programming book? Which remains unfinished after 56 years in progress.

I think when yaks aren't procrastination, they might be tunnel vision. You're so focused on the right solution, you miss the good enough solution.

Yaks as tunnel-vision

A lot of yak shaving happens because you get an idea for the right way to solve a problem and become so focused on that solution that you miss easier less good solutions.

Just last week I noticed what looked like a leaky transactions issue. You'd try to submit an order and sometimes get an error about unique constraint violations.

I dug into the code and omaigod whatisthis it's peppered with db.session.commit statements. These seem to write objects to the database before they're done setting up. We write, then read, then update, then write again. That first write may have temporary values which trigger database errors.

This felt wrong to me. That's not how you use database transactions!

I spent 3 days studying documentation and reading code from the bowels of Flask and SqlAlchemy to figure out how transactions are meant to work. Every change I tried to fix the issue broke our code. I still don't understand how this thing decides when to start and end a transaction 🙃

Pulling my hair out over lunch one day I explained to a coworker "Look people are triple clicking this button because it's a slow operation and then our code tries to write things in parallel and ... waitaminute!! 💡"

This wasn't a transaction problem! It's a UX problem!

After lunch I added a loading state to the form. This gave users feedback that something is happening and disabled the button while our backend processes the request. The issue went away and I didn't have to re-write half our server code to avoid the read-update-write pattern.

Yes the problem isn't fixed. But the UX is better, I learned a bunch about our frameworks, and there are plenty of other fires to fight. Better!

This whole time I was shaving a yak that could be side-stepped! You don't always have to go through a problem, you can go around.

But you won't realize this until you stop and look around. Also known as hammock driven development.

Cheers,
~Swizec