Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
July 28, 2021
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Why I Hate "lazy devs"

by Paul Allen on 01/28/16 08:05:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


Like a lot of people, I used to blame "lazy devs" for shoddy games. How hard can it be to create a game that works? Surely if those lazy devs got off their backsides instead of spending all day rolling around in our money they'd at least be able to create something that worked!

When I joined the game industry it started to dawn on me that, by and large, there are no lazy devs. There are a lot of underpaid, over-worked, stressed and extremely passionate devs - but I've never met one that I'd characterise as lazy. It's a cut throat industry, with a lot of people wanting to get into it (building games is cool), so it's not an industry that lends itself to laziness.

This is why I hate "lazy devs", because that label is wrong.

The devs are the people that create games, the ones working hard to build features, create levels, animate characters, invent stories that transport you and me into far flung adventures.

But they're not the ones that make the rules or change things mid-development.

When development of a game starts the studio will typically create a Game Design Document and a Technical Design Document. The GDD usually encompasses what the game is, what it will be like to play, types of levels, characters, story etc. It's the game template. The TDD is the technical version of this and will include such things as the code requirements, animation parameters, workflow etc. From these documents, and potentially other documents, the plans and timelines will be drawn up to estimate how many devs of which type will be needed and when. That has to fit within the timeline the studio has for release, and the financial and marketing parameters. So there may be some to-ing and fro-ing on the documents and timelines.

And this is where the problems start.

It is borderline impossible to accurately gauge how long it will take to create any significant game from zero to complete. There are too many unknowns. So time needs to be included in the planning stage to allow for hiccups and problems - this is not something a studio with a limited amount of funding or time wants to hear, so this time is often not factored in by the studio.

And then of course, you almost inevitably have someone who changes things part way through.

A focus group has been shown an early build of the game, and reported it needs a new feature. Or the CEO has read a new book and insists on changing a storyline. Or the game designer walks in one morning with a crazy idea that'll make the game "truly awesome". Making changes like these take time, especially if it's a fundamental structural change to the game and the project is fairly advanced. This is not the devs' fault - they're working to a plan decided by someone else - it's the fault of whoever decided it'd be a reallllly cool idea to make that change.

Yet we still blame "lazy devs".

By making these changes part way through development, or adding things, or changing direction, or simply not giving enough time for Murphy to work his inglorious magic, studios basically guarantee the game will not be ready on time for the deadline decided at the start of the project. So something has to give. You can't say a game will take 2 years to develop, then add 25% more work part way through and still expect to hit the original 2 year deadline.

Sometimes studios may put back the release date to compensate - this is actually a good sign, because it shows the studio has both the financial resources to continue and the guts to admit the game needs more work. More often though, the studio is tied into a specific release date, and if that does not change we end up with a mess at release that can sometimes take months to fix. How many games have you played that were a buggy mess at launch, but reasonably playable a few months later? This is why.

So please take this advice. Next time you see a shoddy, late, buggy, incomplete game, take a moment to think before launching into a "lazy devs" tirade. The chances are you're blaming the very people who tried hardest to make the game you're playing great.

Instead, ask the question, "who made the decision to release the game in this state, and why did you take that decision?"

(blog post cross-posted from

Related Jobs

Mountaintop Studios
Mountaintop Studios — San Francisco, California, United States

Lead Tech Artist
Mountaintop Studios
Mountaintop Studios — San Francisco, California, United States

Data Engineer
Mountaintop Studios
Mountaintop Studios — San Francisco, California, United States

Senior Gameplay Engineer
Mountaintop Studios
Mountaintop Studios — San Francisco, California, United States

Senior Engine/Systems Engineer

Loading Comments

loader image