How Projects Run Late, in the small

Today I was working on a project and I've been doing my best, given recent discussions concerning Godus and Peter Molyneux, to do some reasonable thinking about how things will go before I do them, and then jot down an estimate which I compare to real time after the fact¹. Here's the story of one of those tasks, a tiny little task which is a microcosm of game programming (and indeed, game development as a whole).

It was simple. I just wanted to add a little close box in the upper right hand of a dialog box, and make it so that when I clicked on it, it closed that dialog box. These dialogs are rendered by my own code, rather than an operating system, and so I'm responsible for that sort of thing. 

The code for this project is *dead simple* at this point, and so I estimated this task at about 15 minutes. Five to draw a little box with an X in it, and five to deal with the mouse-handling logic, and five of buffer because hell, something always goes a little bit wrong. Sure, I could have doubled it and marked it down for an even twenty minutes, but I didn't. This couldn't really go *that* wrong, could it?

Well, I tossed in the logic to draw the box and all that and it worked first time so I was already ahead of schedule, it took about three minutes to do that. Excellent! Here I am, ahead of schedule and half-way done.

I threw in the logic next to handle the mouse click. This was really simple code: if the mouse position is in the box when clicked, change the state of the game to not display that dialog. (Like I said, this project is *dead simple* at this point.)

Huh. That didn't work. That should have worked, shouldn't it? Well, double-check the code, run with the debugger and we'll have it sorted in no time.

Now, I'm working on my Mac and using DLLs for my game logic (inspired by Handmade Hero) and between not being a long-time Mac dev and some stuff with Xcode of which I'm not fond, just stepping through this code sensibly takes a little bit of time. Sure, it might have been better on my PC, but I'm not working on the PC today, oh well, better remember next time to pad my estimates a little more when I'm working on the Mac. Still, this is maybe two minutes of fiddling, still plenty of time left.

I step through the response to the mouse click and it just jumps over my test and says I haven't clicked the button and I scratch my head with the hand that hasn't just clicked the button. UI stuff is always fiddly, too, because you sort of need to hold the mouse down while you step over your event processing stuff, because while you're in the debugger, those things are going to queue up and so I do it a few more times to make sure I'm doing the right thing here, just getting a down event and not an up, all that.

Huh, well, we've reached that 15 minutes and we have no idea why this isn't working. 

So I look a little more closely at the input logic. I mean, I've used this code on this other project I'm working on and it's just fine there, I don't know why it wouldn't... oh dear.

See, I had copied that logic out of that project before I found this exact same bug over there, and while the details of the bug aren't relevant, the way your mind plays the trick on you of thinking a bit of code is tested and ready is. It takes me another five minutes having figured that out to dig out the code I really want, remove the broken code, and get it all going so I can show that it is now working as promised.

But of course, it isn't. Because my double-click logic in this new project is eating up these mouse clicks (in error) and the single-click I actually want isn't getting through to this code. Ok, tidy that up... and... yes, okay, there, it works. Lovely. I check that in, look at the clock and see that here we are, just over thirty minutes into a 15 minute task.

I've been programming professionally for almost twenty years and I can't estimate reliably a 15 minute task. I mean, sure, most of the time I probably do, but there's no knowing when I'll miss. To a degree, I generally estimate better at less granularity, but properly figuring out how long a bigger task will take involves lots of little tasks like these. And this is an example where I know *everything* about the code, I've written it all myself. Add in a team of coders and fixing even a simple bug without breaking something else rapidly becomes a danger-ridden process. 

Of course, these are the simple problems. One little bug in a 15 minute task doubles its time, and you can't know which one of those simple tasks it'll be. This isn't even a particularly creative problem, where you might spend a fair bit of time on a solution and discover that the solution you've designed just doesn't work -- because it's a design that is meant to be fun, and in the end it isn't, and you have to figure out where to go from there and the schedule is blown.

This is not a business of products. We are not simply making widgets more efficiently to increase profits by .001 cents per unit. We're making things, usually new things, and because we're chasing the technology dragon², the years of experience we have often amounts to very little. All the experience in the world can't help you when the measures are enormous and enormously subjective. 

I can tell you how many lines of code I can write in a day; it's quite a lot. But I can't tell you how long it'll take me to write the lines you actually want. Not even after all these years.

¹I've also strained today to mostly avoid social media, so that my undivided attention is on these tasks as I do them.

²Every few years, drastically new hardware. Every few months, increased expectation from those who play our games. It's Sisyphean.

This blog post originally appeared at http://www.brettdouville.com. You can also follow the author on Twitter at http://www.twitter.com/brett_douville.