The locker that said it was impossible

Software is designed, implemented, and deployed. Then it reaches the people who have to use it.

Those people are imperfect. So, naturally, the software is imperfect too. Artificial intelligence doesn't change that. It just gives us new ways to make the same mistakes faster.

Today I discovered one of mine.

My Canarian acquaintances tell me that I can go to the beach, leave my things on the sand, and get into the water. Maybe they're right. I don't have quite enough faith in humanity to test the theory with my keys, headphones, and phone, though. For the last few days I've been renting a small locker a few steps from the sea. You pay by the hour, receive a code, open the locker, leave your things, go swimming, then come back and collect them. Easy.

Until the code doesn't open the locker.

No key. No headphones. No phone. No way to contact support.

Common sense says: find a phone and call them. I walked back to a Cuban restaurant, where someone kindly let me make the call. That got me into the next part of the experience: a conversation where I explained that the code did not open my locker, and the person on the other end explained that this was impossible.

It doesn't happen. The system works. The code is correct. The problem, according to the system, is somewhere else.

This is the world many software products are designed for: a world where every expected step happens in the expected order. The payment succeeds. The code arrives. The code opens the locker. The customer has a phone. Support can be reached. Nothing needs to be questioned.

But the customer is standing outside the locker without a phone.

Now I have to wait until tomorrow, return to the place, and hope that the problem can be sorted out. Maybe the police will be needed to recover my things. A minor inconvenience, perhaps. Still, it is a very clear reminder that a software flow doesn't end when the happy path reaches production.

There are humans at the end of it. Humans lose phones. Codes fail. Customers describe problems that the support script says cannot exist.

The software doesn't need to be perfect. It needs a way out when it isn't.

That way out might be a physical override, a second access method, a visible emergency number, or support staff who start with the possibility that the customer is telling the truth. Any of those would have been useful today.

Instead, I have a code that doesn't open my locker and a support conversation that says this cannot happen.

We'll see what tomorrow brings.

← Back to Blog