Scheduling Tools

Scheduling tools is tricky business.  Most tools aren’t even started until they’re needed, unless you’ve got some very forward thinking management (an unlikely scenario at many game companies).  The time constraints are impossible since they’re in sync with an equally impossible game production schedule, and budget constraints can be equally constricting.

So, how do we get tools into the developer’s hands as quickly and cheaply as possible, while still delivering high quality software?  Well, if you’ve heard of the quality-speed-cost triangle, you know that if you have to have high quality, and you need it fast, then it’s going to be expensive.  Most game companies choose cheap, fast and low quality when it comes to tools, but I believe we can wrangle the schedule a bit to get pretty fast, pretty cheap and very high quality.  Unfortunately, it takes a great deal of upfront planning to get there – something game developers aren’t very inclined to do.

First of all, schedule in design.  At least 25% of your total time should be devoted to designing the tool.  If you have a week, schedule an entire day (or two).  If you have a month, schedule a week.  If it’s a large project with a GUI, include a mock-up of the the UI.  The design should also include a list of features for each of the other milestones in as much detail as possible as well as goals for each one.  These go beyond features to explain what all the features are meant to achieve.  A milestone should meet these goals, and not just the features, to be considered complete.

After the design is finished, the next major milestone (there may be smaller milestones in-between) comes halfway through the development process and is what I’m calling the “first usable version”.  This is similar to the “vertical slice” almost every game has to go through these days, and includes core functionality only.  The goal is to deliver a tool that the developers can use to get their work done, and isn’t meant to be pretty or user-friendly.  Subsequent milestones will add usability features to the tool.  It take a great deal of planning to pull this off without creating work that will get thrown away later, which should be carefully considered in the design phase.

The alpha and beta milestones deliver the final promises on quality.  It’s useful to sit with the representative users and get feedback on remaining issues. Formal usability studies can be performed if time permits and those problems addressed.  The final deliverable should include documentation on using the tool, something that has been sorely lacking in the game industry.  Too many times, frustrated users turn to the developers for help on common problems which could be easily documented, saving everyone a great deal of time.  Tutorials are also important, as they can give users a chance to see how the developers intended the tools to be used. 

 As you can see, we’re able to extended the speed side of the triangle to reduce cost and improve quality, and add a stop-gap in the middle to get users up and running quickly and cheaply.  When these components are included in the schedule, then we are not only able to get something to the users in a timely fashion, but we can also (eventually) deliver something of high quality, as long as management doesn’t see the first usable version as finished.  They must be informed that the first usable is something to build on, and not at all final, and that increasing the usability of the tool beyond basic functionality will improve the development process greatly.

Of course, this is just one aspect of scheduling tools, but any more detail would too long for this blog.  Maybe we’ll talk about the other issues in an upcoming post, or you could leave a comment describing your own process.