“Steve, can you help us out? We’re having some problems.”
They came on the Sunday afternoon, about 10 years ago. I was in the office to get some programming done in between all the administration. The other project had decided to set its Alpha Milestone day to be the Sunday; one step up on the usual practice of making it Monday to force everyone to work on the weekend.
It turned out that all the designers, who had come in to throw content into the maps, couldn’t get the game to run. The pre-built executable supplied to artists and designers just locked up when the game was started.
“No-one can get any work done!”
By some freak of fate, even though it was Alpha, I was the only programmer at my desk. Unlike the good Samaritan, I crossed over to the other side — of the office — to help out.
Boot game, select a level. Mmmmm: a lock-up with no assert firing, which was quite an achievement with that codebase. (Everyone had been forced to read Writing Solid Code when they started at the company. As a result every code clause was littered with asserts. It would be an interesting exercise to compare the time spent waiting for all the asserts to run versus the time saved by the number of cases they caught.)
I have a personal challenge to try to resolve any bug without ever firing up the debugger. It helps me gather as much context as I can, without being led down a mental alleyway by a machine. Most of the time you can manage without. So let’s run through the usual check-list.
“Did anything change in the codebase yesterday?”
Check the logs: It was fine the day before, and no-one had put any more code into SourceSafe 1 on the Saturday. It can’t be anything in the data, since that hasn’t changed either.
Time is tight, so there’s one thing for it; install the debugger on a designer’s machine, fiddle with licences to get it run, and fire it up. Run the game. Drum fingers, since it’s not the fastest-loading game ever, particular on debug. Soon we get a compiler breakpoint since divide-by-zero is detected, that rare beast.
There’s no source available, but a couple of second looking at the callstack… and that beautiful moment when it all snaps together. The countdown of doom!
With the mordant humour associated with projects Deathmarching their way to the end, Programmer R had decided to implement a bonus feature where the time left to Alpha was prominently displayed as a ticking countdown, under the heading “COUNTDOWN OF DOOM”. It read the realtime clock, subtracted it from the alpha milestone value to get the result.
I’m sure it raised a giggle, but not when the code got to 0 days left. When that happened, the code divided by the number of days remaining — and then it divided by zero. Bang.
It would have taken several hours for me to pull down the code and data, apply a fix, test it, build and upload a new version, so it was time to fire up the mail client.
From: Steve To: Project X designers, Project X artists Hi, If you're in on Sunday, to get the game to run, change the time on your devkit's realtime clock. To do this [instructions follow]…
From: Steve To: Programmer R. Hi R, Could we have a chat on Monday?I don’t have to do this nowadays. I’m not in the office of a weekend.
1 Yes, SourceSafe. It was fashionable up to ten years ago.