Few things are more maddening than standing around idly while we wait for something to happen. It's been proven through experiments, surveys, and numerous real-world examples. The solutions to the problem of waiting are often surprising.
For instance, executives at a Houston airport once solved customer complaints about long baggage claim waits, but not in the way you might think. They first reduced waiting times within acceptable industry standards by hiring more baggage handlers. But, customers still weren't happy. The executives analyzed the problem more critically and discovered that the average passenger spent about 88% of their waiting time standing at the baggage carousel.
So they tried something completely different---they moved the arrival gates and carousels as far away from each other as possible. It now took passengers six times longer to walk to their bags---yet the complaints almost completely dropped. They were still waiting just as long, but most of their time was spent walking rather than standing idly by.
There's also the well-known story of the occupants of a New York office building who complained about how long it took to wait for an elevator. The engineers argued that, because of the age of the building, there was no economically feasible way to make the elevators faster. A young psychology graduate suggested that instead of finding an engineering solution, installing mirrors in elevator lobbies would alleviate the problem. And it did. People still waited but could now look at themselves and each other surreptitiously. The complaints stopped.
So, the issue we have isn't really about waiting. It's about a specific kind of waiting---waiting idly. There's a big software lesson in here.
We spend a lot of time as developers trying to shed milliseconds off of response times. Improving the speed of an application usually results in happier customers. But, over time, it gets harder to find those shed-able milliseconds. There's a point where the returns of brute-force faster performance aren't necessarily worth it.
However, we can look at other solutions with this little nugget of human psychology in mind. With DoneDone, we use Amazon's Simple Queue Service to offload work like sending emails and Slack notifications away from the actual user request. In other words, when you create an issue, DoneDone doesn't instantly process emails and notifications for that new issue. This would increase the time the creator sits idly waiting for the page to respond.
Instead, that information is pushed to a queue. At some point later (perhaps as long as a minute depending on bandwidth), the information is consumed by separate worker processes that handle emails and notifications. In the end, these get sent out later than if they were done synchronously---but the user doesn't spend that extra waiting time idly.
I've often seen this approach in other applications. When exporting a large data set, for example, some apps will send the resulting file via email ten or fifteen minutes later rather than process the export synchronously with the request.
As developers, we might see this only for its technical merits. It's smart architecture. It's a way of reducing cycles at the web server level. But, there's a whole lot of psychology at play here. Those fifteen minutes you have to wait for an email aren't idle minutes. You can get on with your next task or break for lunch. You might not even get to that email for a few hours. Yet, even waiting just a minute for a spinning wheel might have you considering another tool.
Consider it the next time you're faced with any kind of software issue. There might be an unexpected way to make people happier without actually solving the perceived problem.
