The problem with slow tools
Slow developer tools have costs beyond just the time they take. We should invest in ensuring they are fast.
I’ve been bothered by some slow tools lately. Waiting for them to run has given me time to think. How much time are they actually wasting? Let’s say I run a build 15 times a day and have to wait an average of 1 minute for each build.
That doesn’t seem too bad, right? Well, if you do the math, 15 minutes a day times 230 working days a year equals just shy of 60 hours - or 1.5 work weeks - wasted per year. Multiply that by the size of the engineering organization, and this starts to look pretty expensive1.
But here’s the thing: That might be significantly under-estimating how bad this is.
You see, humans aren’t machines. You know it, I know it, but it can be easy to miss what it means when you look at math like 15 * 230. Here’s one relevant difference: machines can stop, wait for some process, and resume right away afterwards as though nothing had happened. Starting and stopping doesn’t matter to them2. I am not a machine3 and do not freeze and stare into space while waiting for tools. I check Slack, I check Hacker News, I get distracted.
This is a problem in a few ways:
- A quick delay can accidentally into 5 minutes of reading Slack. The latest posts about Stonks are just too amusing.
- I lose context on what I was doing. If I had achieved the elusive productive state of focus (a ‘flow state’), that’s gone clear out the window chasing after a squirrel. The productivity boost I get from having everything in my head is gone.
- I have to redirect my focus back to what I had been working on. Shifting focus is a natural thing to do several times a day, but there’s still a cost each time. It takes a little bit of my depletable reserves of energy and willpower. After bringing my focus back to the work a few dozen times, it starts to feel harder to do.
A 1 minute pause doesn’t just cost me that minute of productivity, it has costs that linger long after the pause is over. It’s like hitting a stoplight when driving. After the light turns green, your car doesn’t immediately get back up to the speed limit. It takes a while to accelerate. During that acceleration, you’re moving slower and using more gas. Removing a 1 minute pause might mean I get the task done 5 or even 15 minutes sooner.
And getting blocked by my tools is super frustrating. I’m trying to get something done, but these random roadblocks keep halting me in my tracks. It’s like being in stop and go traffic all day long. Getting out and walking might be slower, but at least it would be less frustrating because I wouldn’t keep being forced to stop. If an office can afford creature comforts like La Croix and extremely tiny bags of snacks, maybe saving our sanity can also get room in the budget?
There might be another, subtler cost of slow tooling. Remember the whole ‘developers are human’ bit? As it turns out, humans don’t follow fixed, pre-programmed behavior. When faced with frustrations, we change our behavior in response.
How might our behavior change in response to tests being slow to run? We’ll try to avoid running them. We’ll probably write fewer of them, because we know that writing them leads to running them, and running them leads to waiting, and waiting leads to the dark side.
What about environments that are slow to build and slow to switch branches? We’ll try to only do those things when we really have to. That small cleanup I could write in 30 seconds? Nah, I don’t feel like wrestling with tooling for 5 minutes. That idea for a better approach I thought of? Eh, what I have is good enough - leaving the code a bit messy is unpleasant, but dealing with that tooling would be worse.
So to summarize, slow tooling causes productivity losses greater than you’d expect based on the raw amount of time it takes because of the distraction it causes. It changes developer behavior in ways you might not like. And it frustrates my socks off.
If you are in charge of some developer tooling, please take the time to understand how often during the day it gets used, and how long it takes to run in real world cases. It’s all too easy to fall into the trap of thinking the tool you are maintaining is fast because it’s fast on your machine. Your machine probably has a clean state, without all the other tooling running at the same time constantly fighting with each other to see which can make the bigger mess of the build directory. Measure how long it takes for real users.