Time Estimation

The Fundamental Difficulty

Time estimation in software has been a problem since the earliest days of programming. Tim recalls learning about the COCOMO model in his 1980s engineering classes — a model that took lines of code as input and produced man-months as output. Even as a student, he saw the obvious flaws: how do you estimate lines of code in the first place? What about the type of code (UI code takes far longer than gameplay systems)? What about programmer experience level? The question is inherently complicated and differs across disciplines — programming, art, design, and sound each have their own estimation challenges.

Tim also emphasizes that estimation is highly correlated with crunch. People tend to blame one side entirely — either the estimator is terrible or the manager is unreasonable for asking — but the reality involves responsibility on both sides.

As a Junior: Ask Questions and Break It Down

Early in his career, Tim was typically given estimates by senior programmers. His key advice for juniors:

• Ask why the estimate is what it is — "Why do you think this is a week?"
• Request a daily breakdown — if you haven't finished day one's tasks by end of day one, you're probably not finishing on time
• For large tasks (weeks or months), push for hourly or daily granularity
• Communicate immediately when things diverge from the plan — whether you're ahead or behind

The Bard's Tale Construction Set Story

Tim's most vivid example: on only his second game ever, he was told the entire Bard's Tale Construction Set would take 14 weeks. Two major problems surfaced almost immediately:

1. The UI was the real time sink, not combat as predicted — particularly animating creatures with delta-compressed animation frames, which was outside Tim's skill set entirely
2. Combat was not a "black box" as promised — the code was riddled with magic numbers like if monster type equals 52 with no enums or documentation

Because Tim investigated immediately and could show concrete evidence ("look at this code — this is not a black box"), the team added another programmer (Phil Britt) and adjusted estimates. The lesson: early investigation and honest communication saved the project.

As a Senior: Base Estimates on Experience

When you're the one being asked for estimates, Tim recommends:

1. Compare to previous tasks — if you've done something similar, base your estimate on that history
2. If it's genuinely new, tell your manager honestly: "I've never done anything like this. Let me break it down, start working, and report back after day one"
3. Accept that pushback is part of the process — managers pushing for accurate estimates is literally their job, not an attack on your competence

Tim stresses that estimation is always possible but not always accurate — and you still have to try. Unless you're indie, someone is funding the project and has a right to know where their money is going.

The Dangers of Underestimation

When you underestimate, three things happen:

1. Features get cut — the work simply can't be completed, and designers have to fall back to simpler alternatives. Players end up with missing inventory sorting, no item tagging, no junk categories — they don't know about your process, they just see a worse game
2. Bugs ship — you technically "finish" but without time to properly test or optimize. QA inherits your technical debt
3. Crunch — if the feature can't be removed, someone has to do the work, and that means overtime

The Dangers of Overestimation (The "Scotty Method")

Padding estimates — saying four weeks when you think one week — seems clever but backfires in two ways:

1. Features get dropped preemptively — your inflated estimate causes managers to cut features that were actually feasible. Tim experienced this as a designer: he got a large estimate back, didn't push back, used a fallback design, and shipped without the feature. Later the programmer admitted they could have done it. Players were disappointed for nothing
2. You get exposed — if the task is reassigned to someone at your level who finishes it in the original timeframe, you're now known as someone who pads estimates. This reputation compounds over time across projects

The TLDW (Too Long, Didn't Watch)

Tim's three-part recommendation:

1. Understand the task — ask questions, compare to past work, investigate before committing to an estimate
2. Break it down — get month-long tasks to daily granularity, unfamiliar tasks to hourly. This lets you detect problems early, in both directions
3. Communicate — talk about delays and unexpected speed. Communication is two-way; you can't blame your manager for poor communication if you're not initiating it either. Tim acknowledges many game developers are introverts (himself included) but insists this is a skill you must develop

The core message: estimation isn't about finding a magic formula. It's about deeply understanding what you're building, creating tight feedback loops, and maintaining honest dialogue throughout.