What a robot tournament teaches you about shipping software

A tournament match lasts two and a half minutes. There is no rollback, no hotfix and no second chance to explain what you meant. Whatever you built is what runs.

Deadlines are honest

Match day arrives whether the robot is ready or not. That fixed date changes how a team argues about scope. Features that would have survived a month of discussion are cut in an afternoon, because everyone can see the calendar.

Test the ugly path first

We used to test the happy path and hope. Now the first test on any new mechanism is the worst case: a dead battery, a dropped part, a driver who panics. If it survives that, the normal case is easy.

Document while it is fresh

Every event ends with a short written review: what broke, why, and what we would change. Those notes are the reason our second robot was better than our first, and the reason our software projects start with a failure log too.