What 298 teams taught me about edge cases

The Schott Classic database holds 298 teams across nine tournaments and five years. That's 298 captains, each a fully independent chaos generator, stress-testing every assumption I've ever baked into a system.

Software people talk about edge cases like they're rare. Run a tournament and you learn the truth: the edge is where everyone lives.

A field guide to real edge cases#

The tie. Single elimination can't tie, but pool play can and does. The first version of the standings logic assumed a winner. Wiffle ball did not cooperate. Now ties are a first-class result - allowed in pools, factored into seeding.

The phantom roster. An official win requires three rostered players present. So what happens when a team plays with two ringers and a guy whose waiver never arrived? That question is why rosters and waivers are digital, chased automatically, and checked at the field - because it came up, at the worst moment, in front of everyone.

The published pool. We once posted pool assignments before they were final. Teams changed; the printouts were instantly wrong; confusion compounded all morning. The fix wasn't better printouts - it was a rule: nothing is public until it's final, and the system is the only source of truth. Every data product I've built since carries that scar.

The shirt size. One year, one team, no Medium. It sounds trivial - it's a spreadsheet cell - but multiply "one small tracking gap" by 298 teams and merch, food counts, and beer orders all drift. Now sizing is captured at registration, not at the folding table.

The rule that only breaks for some users. Pitching in this tournament runs on gentleman's rules, agreed pre-game. Worked for years - until the Women's division told us the format wasn't serving them. The fix: allow underhand pitching, shorten their pool games to three innings. The lesson generalizes: a rule that works "in general" can still fail a specific population, and you only learn it by listening.

The loop is the product#

Every year ends with a debrief list - what broke, what dragged, what a captain complained about at 9 PM. That list is next year's plan. My favorite chain: one year's note said "get a quote for inflatable outfield fences." The next year's budget bought them. This year's list already says "need a shed to store the fences." Improvement creates its own new requirements, forever.

That's the whole discipline in miniature: ship, watch real users break it, write it down, fix the top of the list, repeat. I've run this loop with 298 teams of wiffle ball players and with a Division I athletic department, and I'm telling you the mechanics are identical - only the budgets change.

If you build software and you've never operated a live event, borrow one. Nothing else teaches you as fast that your system's edges are other people's Saturdays.