The Two-Minute Timeout

On a broadcaster’s TV app I built the second-screen sign-in: the TV shows a code, you sign in on your phone, and the TV waits, polling, until you’ve finished. The requirement said the sign-in window should be 24 hours. I decided that was far too long for a polling flow and quietly set it to two minutes. Surely nobody takes longer than that.

The bug that only happened to one person

Sign-in failures started coming in. One of our QA testers could never sign in, while it worked for everyone else, every time. Our first theory was the characters she was typing. Perhaps a symbol or an unusual character was being mangled somewhere between the phone and the TV. It was a plausible theory, and we could have lost days on it.

Instead I sat with her and watched her sign in. The answer took about three minutes to appear, because that’s how long she took: she was careful, she checked each step, and she went past two minutes. I fixed the timeout the same day.

What I took from it

• Don’t quietly replace a requirement with an assumption. If a requirement looks wrong, ask why it’s there. The 24-hour window existed for a reason; my “nobody needs that long” was a guess about other people dressed up as an engineering decision.
• Test the way real users behave. Developers sign in fast, on good devices, the same way every time. Real users are slower, distracted, on other devices, using assistive technology. Test data and test timing should look like them, not like us.
• Watch before you theorise. Five minutes beside the person hitting the bug beat a day of guessing. It’s the same instinct behind A Testing Strategy Teams Actually Adopted: get close to how the software is really used.
• Value the people who find the odd ones. That tester was doing exactly what good QA does: behaving like a real user. The “works for everyone else” bugs are often the most important ones, because they’re the ones real customers hit.

It was a small bug, not an outage. But it changed how I treat requirements I disagree with: I question them out loud, I don’t overrule them in code.