Late in a project’s development cycle, ‘what to do next?’ is a very easy question to answer. It’s whatever is next on the list of bugs or missing features.
But for a substantial portion of the development process, the answer to ‘what to do next?’ is very fuzzy. You have a nearly infinite number of missing features, and a bunch of bugs you’re not sure if you care about yet. So what do you work on? When do you draw a line and say ‘it’s time to make some levels now’ or ‘it’s time to overhaul the physics system’?
I have four main goals in mind when trying to make this decision:
- I want to enjoy the whole development project, spread the nasty tasks evenly with the fun ones, so I don’t get bogged down with any one job
- I want to tackle any potential road blocks early on, make sure that everything I am aiming for is technically possible
- I want to create a good, clean code base on which to build and expand on later
- I want solid prototypes continually so I can get a good feel for what the end result will be, and easily change the direction before the code base gets prohibitively large
Every one of these goals conflicts with all of the others. So when deciding between 100+ different things I could do next – each achieving some part of one or two of these goals, while usually negating the rest… It’s a difficult decision.
How a developer decides what to work on next has to be the single biggest factor separating success from failure. A developer who spends forever deciding on the best path to take will waste time, and still not necessarily pick the right route. Randomly picking a task will just continuously create more tasks, with no direction. Focusing too much on one particular goal will suck time away until all that is left is a beautifully coded piece of nothing.
I’m hoping that experience has taught me how to solve this impossible problem. There isn’t an answer to it written down anywhere, and there never will be. But when faced with hundreds of options and many goals, the human mind can do amazing things. With practice, your ‘what to do next?’ solution must get more and more correct.
I’m not really sure what my point is. Perhaps that software projects are hard, and that the decisions that need to be made are impossibly difficult. Maybe that is what makes it so fun.
Hey David, how do you go about starting the process? Do you build a list of features and start working on them one at a time or is it more dynamic than that?
Comment by Glen Young — April 13, 2009 @ 11:12 pm
With Chopper 2 I’ve got a good feel in my mind for what the features will be. Some are still quite generic, and every now and then I flesh out the ones I’m worried about on pen and paper.
The list of features required always starts with one item: make an app that launches and show a window. From there the list grows and grows, so fast that I don’t bother to write them all down. At some point later the list shrinks to a size where writing it down makes sense, but at that point it doesn’t really matter what order you do things in. It’s easy, just a matter of finishing the thing.
Usually my games start with a couple of place holder graphics responding to input. Then I almost always spend a lot of time working on the Level Editor. That way I get some solid data structures early on, and get a feel for what the workflow will be.
After that it’s iterating over both the editor and the game, making refinements, adding features as they become obviously missing, and sometimes re-coding huge chunks as they become inadequate for the job.
But to answer your question, it’s very dynamic. I rarely know what I’ll be working on next until I complete the current task, and in the early stages the list of missing features is just a fuzzy concept, not really a list at all.
Comment by David Frampton — April 15, 2009 @ 5:27 am