Why are game updates so slow?

Often, players cannot understand why game companies seem to move at a glacial pace with updates. A bug hangs around for months before being fixed, and the question is why?

Because we know what we're doing.

The clever among you might say, "If you knew what you're doing, there wouldn't be bugs!" To which a retort along the lines of "grow up" occurs. But let's not go there. Let's talk about why bug fixes happen the way they do.

First, a game is released. The world into which it is released is a very different world in which it was tested. There are usually dozens of professional QA testers banging away on the game for months, then hundreds of beta test volunteers, before the game gets to the real world. But the real world is hundreds of thousands of players, playing all hours of the day and night, with tens of thousands of different computer software and hardware configurations, all kinds of network connections, and all possessing different brains.

A once-in-a-million hours of playing bug will happen in a game with 200,000 players at least a dozen times a day. So bugs will happen in release conditions because there was no conceivable way to instantiate it prior to release. So, we're clear that there will be bugs, and the relative ease of players being able to find them is in no way indicative of "lousy QA". It's indicative of "finite QA" that is not amenable to change. There will never be able to be enough QA to release a reasonably-complex product that is bug-free.

That said, once bugs are identified, generally the development team is often already developing their next thing. They're already knee-deep in something else. Whoever is responsible for fixing the bug has to move between their current task and fixing the bug, moving between different codebases that may have very different functionality. If the bug has no reliable repro steps, it can be an arduous slog through logfiles to see if there's some fossil evidence of what was happening when the bug occurred. When there are many variables at play, tracking things down and fixing them reliably is a difficult task.

Once a fix is identified, that's just the first step. Systems are interrelated, and fixing a bug can be pulling on the loose thread of a sweater: it can lead to more issues, or expose more bugs that just haven't surfaced yet, or it can uncover a class of behaviors that might be relevant to other systems, and those will have to be checked. This can be a long process to wrap up: when you're dealing with systems of significant complexity, nothing is cut-and-dried. Then everything has to be QA'd to make sure nothing has been inadvertently broken with the fix, and depending on the system involved, this QA can be extensive.

Companies cannot release patches for every little thing, all the time. This is not the amateur mod scene, where bugs are tolerated because the product is free, and is understood to be an amateur effort. Companies want your money, and people rightly expect excellent performance and stability for their dollar. The importance of being sure everything works as intended is part of why it takes so long to make changes.



IEEE Spectrum’s gaming blog was retired in 2010, but it is preserved here for archival reference.