How to Estimate Task Durations

You are always expected to estimate task durations. It is especially hard to do for development tasks. You get better in time but game projects frequently put you into unfamiliar territory.

Add realistic error

Unfortunately, how much error is realistic depends on many factors. If you actually need to retrieve that information from a blog post, we can safely say it is more than 2x in your case.

Say, your initial estimation is one month. If you have done it before, stick to your estimation. Otherwise, 2 months.

Estimation was 3 months. Your performance will consistently decrease. If you are experienced, expect two weeks delay. Otherwise, 8-9 months, there is no way an inexperienced developer can plan 3 months of work accurately.

Now, those were only for single person tasks.

Let’s say it is the first task of your newly formed team and you are the fresh, inexperienced lead. Your initial estimation was 4 months and you completely overlooked the upcoming storming stage. Everyone seems bright and get along really well, after all.

Now when it begins, you don’t want to be out in the open. So what you do is, you get behind the junior artist, as the Wacom displays are expensive, nobody will dare throw things at you.

The project will likely end up in development hell, and get cancelled, but not before everybody hated you. Bottom line is, always take stages of team development and decrease in performance into account.

Don’t stare into the abyss

You realized you don’t know how to do X. It is OK. Don’t stress over it. The unknown seems so hard it makes everything else look simpler. They are not simpler. Don’t let fuzzy parts of the task completely drive your estimation.

Visualize the steps

Don’t just outline the task and focus on the duration of each bullet. Visualize the complete pipeline instead. For a second, be overwhelmed by the amount of minor labor and glueing needed to complete it.

Reorganize the task

Don’t worry. Your estimations will get better. But that is mainly because with experience, you learn how to reorganize and regroup the tasks in ways that makes them more meaningful from a task management point-of-view.

About Knowledge

There is a particular kind of person.

The kind that has once heard the aphorism “knowledge is power” as a kid, and taken it all too seriously. The kind that could probably spell the Latin version of the phrase. The kind that poured most of their stat points to “wisdom”, hoping to be the wizard of the story.

Of course, one rarely questions what “power” actually is. Let’s define it as the ability to influence the state of the environment as well as the behaviour of its agents.

Knowledge definitely was power, once.

The new world weakened it. The characteristics of what we call knowledge is vastly different and more fragmented now. It is still important, maybe even more so, but not nearly as powerful.

I like to retrofit one of the notes from Newton’s alchemy texts to depict the new knowledge.

The vital agent diffused through everything in the earth is one and the same. And it is a mercurial spirit, extremely subtle and supremely volatile, which is dispersed through every place.

The new knowledge will change whenever you are sleeping, whenever you look the other way. It will change whenever you blink.

It will regress, and it will get revised and deprecated. It will be staged, and it will be branched.

The new knowledge, is a repository in version control. As such, it needs an active maintainer.

In a world of assets and liabilities, knowledge is only potentially an asset, but always a liability.

The good thing is, even though it doesn’t make you more powerful, it definitely makes you better. It gives you perspective. It gives you the ability to fill the new, interdisciplinary roles that are emerging, as long as you actively maintain at least one of those repositories.

I am a programmer, with knowledge and experience in computer graphics. I studied architecture, and I did organization/event management for some years. I settled on game industry, not only because I love games, but also because I can apply all of this knowledge in games.

Whenever people ask me why I include my work as an architect as vocational experience in my game developer CV, I remind them of a particular architect:

Christopher Alexander, whose research in patterns of architectural design and urban planning in 60s helped shape how we design large scale software projects today. His work was required reading in CS circles. He heavily influenced the research on Object Oriented Programming, as well as the design of C++. The whole Design Patterns movement was solely based on Alexander’s work.

Job titles are products of a well-defined, well-tested distribution of work. Not a definitive categorization of knowledge and expertise. Multiple areas of knowledge may be hard to actively maintain, let alone to apply. But they are meaningful, as long as you are able to specialize on one. The others, even when deprecated, will keep making you better.