Hacker News Reader

Comment by asoneth | Hacker News Reader

Reminds me of an apocryphal story of the engineer tasked with speeding up elevators in a tall hotel. After evaluating all the options, they ended up adding mirrors next to the elevators. The guest complaints about the slowness of the elevators decreased as people pushed the button to request the elevator, noticed their reflection, checked their hair, and before they knew it the elevator had arrived.

(I do not know where this story originated, but ever since hearing about this from one of my design professors I've noticed how many buildings put mirrors next to their elevators.)

View on HN

I know this is apocryphal because I’ve never met a single engineer who’d identify that kind of human-centric solution.

Rubbish. Good engineers will think laterally about what they can do to make the product work better for the customer, and this is especially true they're in a tight technical spot. Everyone can get railroaded by their thought process and be blinded to the easy, simple solutions, but a good engineer is supposed to be aware of that.

More likely, the lift engineer (or team) is only allowed to "make this lift 20% faster" and is told to stay in their lane when they suggest non-lift-based ideas.

In all likelihood, the engineer is employed by a company in order to sell expensive lift upgrades, not mirrors or interior design services. And his boss has a target.

There's a similar bit in the book Alchemy by Rory Sutherland where he talks about trying to increase trains reliability or the satisfaction from a gas engineer callout. Turns out people just really don't like uncertain waiting. Making trains on time or predicting when an engineer will arrive has too many variables to really solve. But a live display of trains with delay times, a expected arrival window with promise of a call 20 mins before arriving, is enough people know if they can go to the loo, or nip to the shop etc. Live train boards can have a much greater impact on traveler reliability ratings then actually making trains more reliable.

Sometimes solving the impact of a problem is much easier then solving the problem.

I do wonder how many train passengers would prefer a system where trains were randomly between 0 and 1 minutes late with no information to guide them on expected arrival time, and one where trains were randomly between 1 and 60 minutes late with reliable information detailing how late they were each time.

It's about uncertainty though so it doesn't really work if you know it will turn up (also 1 minute is hardly a delay).

People would probably choose a system of 0-30mins delay with no info vs 0-60mins with info, if they know thats the rules. 'it'll be here within half an hour' is close enough to knowledge to get the uncertainty out the way which is a lot of the problem.

But if passengers don't know what the rules are or when (or if) the train is coming, and you'll get a lot less complaints and grumbling passengers with a 0-60 full info delay system then you do with a 0-20 with no info. In one you know the train is coming in 47mins. Annoying, but you can tune out for 30 mins, get a coffee, read hacker news, tell a friend you'll be 47 mins late etc. In the other it might be here in 2 mins or 20. You can't even nip to the loo without concern you might miss it. In the first instance you are mildly annoyed but you replan your time; in the second you're on edge for what turns out to only be 8mins, but a highly annoying and stressful 8 mins.

It's the uncertainty that's painful not so much the delay (for small-ish values of delay!)

Totally agree uncertainty is a problem - both when taking public transport and when using computer software - but in both cases it's surely better to primarily focus on ensuring operations aren't delayed unnecessarily, and only once you've got to a point that further optimisations become too difficult or expensive, turn to providing more accurate feedback on expected waiting times. I will say though accurately estimating waiting times (and esp. providing continual feedback on them) isn't always significantly less challenging than reducing them in the first place.

Reply on news.ycombinator.com