I am a programmer. Well, sort of; I program, at any rate. Currently, I’m working with Double Cluepon as their tools and client engine developer. That means that — basically — I’m making Emerald Kingdom all on my lonesome (not really, of course — we’ve got a very solid team here, it’s just that at the moment everyone has other tasks — art, animation, networking, design, writing — and so the tool development is mine.). It’s sort of a daunting task, to be sure; there are literally hundreds of thousands of words in the backstory, we’ve got a webcomic coming up, and my boss is looking for a pretty aggressive timeline to reach Alpha.

And that’s what I’m here today to talk about, because it’s something of a wall that I’ve hit my head against a lot. It’s a big, heavy concrete wall, and it’s filled with spikes. Because Deadlines can be your best friend and they can be your worst enemy.

From Blank Slate To Bank…. Somethingthatrhymeswithslate

The problem with a deadline is, for the most part, you have no clue when the hell you’ll be done with any given thing. This is something that can be winged, and your wild guesses get more accurate as you go on, but quite frankly even three years in the business of software development hasn’t made it any easier. At least, not for big projects. A big project encompasses so much that a 1 hour delay early on could translate into a three week delay down the road. There’s no way of knowing what bugs will crop up, what features will need to get chopped, what will need to get added, so on and so forth. The easiest way to deal with the Long Term Problem is to use a ticketing system (I recommend Redmine, although Trac is….. eeeh, really, it’s not very good, but it is popular. Really, check out Redmine.) to cut up the work you need to do into sizeable, more easily understood parts.

Building a Map Editor is hard; but if I split that up into “be able to paint tiles”; “be able to paint objects”; “be able to scroll with the mouse”; “be able to delete painted tiles or objects”; “be able to specify borders”; “be able to save and load maps”; and so on and so forth, I can eventually come up with a much more reasonable SWAG (Scientific Wild-Ass Guess) than if I just went with the first thing.

Planning is important. Plan modularly, plan in bite-size chunks, but don’t plan too far into the future.

The key to achieving the milestone of your tickets is to not let them overwhelm you. There are eight million tasks to do to make a Map Editor (going with the example below), and as you develop your boss will probably not be happy with some of your solutions. But if you keep things going in a queue and keep knocking out stuff as you get to them and as they come along, a real product will start to form. That’s sort of important. As Joel Spolsky said, “shipping is a feature”.

This is where the actual deadline comes in. You have an idea of how to break things up into reasonable pieces, but you can just keep adding pieces on indefinitely. That’s called feature creep, and it is the worst thing that can ever happen to you.

There are two ways to deal with feature creep:

  1. Plan every feature your game will have in advance, or
  2. Set up milestones and cutoffs.

The second one is the preferable one. Just like cutting up your tasks into smaller problems makes it easier to handle the big part, cutting your time up into set schedules with target milestones makes it much easier to keep yourself honest and moving. When you’re first starting, you should determine how much you can get done in, say, a week, and figure that every few weeks or a month will be a milestone. Then, arbitrarily (just how we like it), you say that no new features or tickets are going to be made for this milestone, and you just work on finishing up what you have. The numbers are essentially unimportant, mostly because they’re so deeply personal and vary depending on the situation.

When does it all end?

The first few milestones, you shouldn’t worry too much about your overall deadline. The fact is, you don’t know how fast you work, and even if you do, You don’t know how the project you’re working on will affect your own speediness or tardiness. It’s only after you’ve spent a fair amount of time with the environment and your code and process that you’ll really begin to understand how long it will take to reach your end goal.

You did figure out what you wanted the product to be, at least marginally, right? Because if you didn’t, you, uh, maybe you shouldn’t be doing this. Seriously. Development isn’t like writing; you don’t get to just make it up as you go along.

Look at how much you’ve gotten done so far, both in terms of the time spent and in terms of the amount of code written and in terms of the actual percentage of the completed project you have. Now figure out how many more milestones will be necessary to reach a testable state. That’s your deadline.

Ticket Prioritization and You: A Field Guide

There are a lot of ways to prioritize your stuff on your way to making a complete product. Frankly, I don’t even know what’s appropriate; nobody’s ever told me. Here’s how I do it on a per-day basis, though:

  • When I’m first starting off for the day/week/milestone, I tend to pick off the myriad simple tasks and tickets that exist: add a text box here, add a button there, fix a small bug over there, head on over to Boise to tweak a graphic.
  • Once I’ve warmed up on a few simple things, I find one major thing to get done, something daunting and scary. I hit that like Wesley Willis until the ticket or my head caves in, whichever happens first.
  • I hate ending the day with unfinished things; if I wasn’t able to finish the Major Thing above, then there’s not much I can do, but if I finish that thing early enough I will go back to picking off minor stuff. If there is nothing minor left to do, then I start to plot out what I’m going to be doing for the next few days, or take minor stuff from further down the line.
    • As an aside, it is useful to plan things at least somewhat in advance. I generally have things lined up for the next few weeks, although the further out those things get the less well-defined they are. For today I will have five or six small tickets, but for next month will probably be one giant monolithic ticket covering a much larger section of code.

On a larger scale, the best way you can prioritize your time (and tickets) is to Consider The Following:

  1. Is what I’m working on a prerequisite for anything else?
  2. Does what I’m working on touch multiple systems, or is it more stand-alone in nature?
  3. Is what I’m working on something necessary to finish something else I’ve already done?
  4. How difficult will it be to implement and test what I’m working on?

In general, you want to try and divvy up your work so everything is modular and can be taken out or put in as you choose, but real life seldom works so cleanly, so the goal is to minimize things mucking about with other things. Once something is not reliant on anything else, it can be put aside and done whenever you’ve got the time.

Just don’t forget about that deadline you promised.

This is a cross-post from my blog One More Level, which covers pen and paper gaming, video gaming, writing, comics, and a more diverse set of topics; I’ve just started daily posting and intend to keep it up until I drop dead, so please do check it out along with your regular reading here.