Crunch, Part 2

1. The College Story

Tim recounts a software engineering class he took in his fourth year at the University of Virginia's engineering school. The class was required for all computer science students — everyone had the same background, the same three years of prerequisites, and very similar schedules.

1.1. The Project

The professor laid out the terms on day one:

• Solo project worth 50% of the final grade — you literally could not pass without it
• The only other grade component was the final exam (the other 50%)
• The project required building a mainframe job queue simulator that could schedule different types of jobs (CPU executables, print jobs, disk writes) using various scheduling algorithms (shortest job first, shortest remaining time first, longest job first, fewest resources first, etc.)
• Jobs could be interrupted externally (user cancellation) or internally (out of memory, crashes, printer out of paper)
• Some jobs like print jobs had to run contiguously; CPU jobs could be swapped with a context switch cost
• The professor would run your executable against his own test input and compare the output

1.2. The Warning

The professor explicitly warned: do not wait to get started. He deliberately assigned very little homework so students could focus on the project. He gave them a full 15-week semester.

2. What Actually Happened

Tim started working on it that same week, spending a few hours a day — often during a 2-hour gap between classes, going to the computer lab instead of the library or dorm. For the first couple of weeks, only he and one other woman from the class were showing up to work on it.

After about a month, other students started trickling in. By the last few weeks of the semester, the entire class was in the computer lab — fighting over terminals, fighting over printers, raised voices, arguments.

Tim finished his simulator a couple of weeks early and spent the remaining time studying for other finals.

2.1. The Results

When the professor graded the projects:

• Over half the class turned in a completely non-functional simulator — it wouldn't even run
• Most of the remaining half produced simulators that ran but gave wrong answers on almost every scheduling algorithm
• Only two worked correctly — Tim's and the woman who had also started early

2.2. The Aftermath

Students complained to the dean that the project was impossible and there wasn't enough time. The dean pulled Tim in separately and asked about it. Tim confirmed the professor had warned them on day one, gave minimal homework to free up time, and that the professor could see from account logs exactly when each student started working. Many students didn't pass and had to retake the class the following semester.

3. The Lesson Applied to Game Development

Tim draws a direct parallel to professional crunch. Looking back over 30+ years in the industry, he recalls coworkers who:

• Spent 2 hours talking about a movie they saw that weekend
• Took really long lunches
• Came in late every day but left at the same time as everyone else
• Were clearly not putting in 8 productive hours

These same people would then complain when crunch inevitably arrived, blaming management entirely.

4. Tim's Nuanced Position on Crunch

Tim is careful to state his position precisely:

• Crunch is bad
• The majority of crunch is management's fault — and sometimes the publisher's fault
• But it is not 100% management's fault in every case
• Sometimes it's the people on the team who bear some responsibility
• Those who claim it's entirely management's fault are often either very inexperienced, have only worked on small dedicated teams, or come from indie backgrounds where everyone understood the stakes
• The people most likely to shirk responsibility are often the ones contributing to the problem

Tim challenges anyone who claims crunch is always entirely management's fault to prove it, because he has substantial evidence to the contrary.

5. References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=eXJkecLBhOE