Schedules

Gantt charts suck.

They're great for work that's like manufacturing, where you have a clear assembly-line perspective on how the work is supposed to be done. Gantt charts are useful for resolving dependencies between different parts and finding out what the gates on development are.

But programming isn't manufacturing. It's not engineering, either. I'm a big proponent of software engineering, but that body of knowledge is more like disciplined craft than engineering. An engineer can plan out what needs to be developed, what each piece needs, and how long each piece will take to build. He can make you detailed drawings on how the piece looks. He'll give you the formulas for all the chemical reactions that go on in your plant. He'll tell you how strong that girder needs to be to hold the weight and stress that will be put on it.

But programmers can't do that. How long will it take to write the AI? Hah! The designers don't even know what the AI will do yet, or how complex the collision maps are, why would a programmer have any idea how long an AI will take?

I've written many different particle systems. I could clone one of my old systems fairly quickly, and also give you an accurate estimate of how long it would take to do. But no system exists in a vacuum. A particle system has to integrate with the underlying graphics engine. You might want to add some constraints to the system to prevent it from bogging down the CPU. And then there's always new features to add halfway through development.

If you ask me to build the same system that I built last year, then we're getting close to engineering. If I built that same system a half-dozen more times, it'd be the sort of streamlined, organized project worthy of being called engineering. But hah! And hah again! The technology moves to fast for that to happen.

New systems are research projects. If we could properly schedule research projects, then we'd have a cure for cancer already. We woulda had one decades ago. But research isn't like that, and most systems in games are new systems, similar to last year's model but with a new twist. There's no good way to figure out how that twist will effect the project until it's built, though.

And that brings us back to agile development. Scheduling is just a loopy fallacy. If it wasn't for programmers being exempt employees (or employers dodging the law and refusing to pay overtime)... well, actually, I think that's the sort of mess that would force a lot of people to reassess how they schedule programming.

An iterative model means frequent releases. Agile development means prioritizing features. You might not know when everything you want will be done, but at least you'll be sure the important bits were done by the time you need to ship.

I'm working on a little sprite editor this weekend. I need both a subset and superset of the tools that most paint programs have, so I'm just building my own. (I wrote my first paint program for the Atari 800 around twenty years ago.) At one point, I was tempted to write down all the tasks that I needed to complete before I considered the editor done, then decided to throw the list away. I don't really need to know when the tool will be done. I know what's important, and I'm doing the big, obviously important stuff first. Things like frickin drawing. Saving, loading, color picking.

I'm not trying to build the uberest components ever, before the app runs. I'm not amassing giant graphics libraries, full of all the latest algorithms and hippest widgets. Screw that. If I need that stuff, I can add it when I need it. Right now, I need a way to use an Eyedropper without having to take my hand off the mouse, or reach across the keyboard (usually meaning looking at the keyboard), with the chance for error and time wasted. That feature? That's in already! Although minimally functional, it's already useful.

And hence another problem with schedules: you might have the most accurate schedule known to man, but if your programmers are busy adding features that no-one will ever use, then you've wasted their time. Your project is less likely to succeed because you were more worried about being 'done' on time than you were about what you had working.

The stuff that slows down programming, for me, is almost always completely outside the scope of programming. Things like 3rd-party libraries being incompatible (from things like XNA not building under Visual Studio 2008, to creating MS Exchange mailboxes on Vista requiring not a simple code library like in XP but a completely separate scripting system). That shit set me back days, on tasks that were, otherwise, only a few hours long. On my current game, the conversation editor took me over a week to complete, when nearly every single other editor took on the order of 3 hours. Why? The design kept changing. (My designer is a fucktard. But all the chicks say he's sexy so I'm stuck with him.)

So, you might ask, how in the world can you schedule if you can't schedule? Again with the iterative development: you'll be releasing on a regular basis anyway. If you have a drop-dead ship date, quick iterations mean you'll have something steady. Prioritize the tasks that you give your programmers, and they'll get the important stuff (and the low-hanging fruit) done. The better your programming team, the more features you'll have at ship. And because they released new builds all the time, it'll also be a robust game.