3 TIPS TO MANAGE TECH QUALITY ON YOUR GAME

[This post was originally part of the in-depth review of PC Building Simulator, where also wrote about how to manage a mature live game. But we felt that it was a topic interesting enough to be published on its own.]

WHY TECH QUALITY IS IMPORTANT?

As games add more content and features, specially if the rythm of development is fast and breaks things, the game losses technical quality. This translates into a wide range of problems that loading times become longer, more bugs appear, crashes and freezes become more common, etc…

It is surpising how many game managers and teams ignore the impact of these types of issues (unless they’re showstoppers). In my experience, this is because the negative impact on KPIs of the loss of technical quality on a game is hard to measure unless it’s apocalyptical (like a massive amount of players having a crash on the loading screen).

But it doesn’t mean that the effect isn’t there. Is just that it usually is a subtle cumulative effect over a long period of time. And we humans are better spotting abrupt changes that can be attributed to specific moments on time.
A game negatively affected by a loss of tech quality could look like this:

HOW TO MEASURE TECH QUALITY?

Before improving something, it’s important to measure it and define several KPIs, so that you can check what is the impact of the improvements, and detect fluctuations.
In this case, some good KPIs to track about tech quality are:

• The amount of bug reports or tech tickets received by customer support per month.
• Amount of crashes or account resets per month (or other showstopper bugs).
• Percentage of crashes on login, or ratio of crashes vs total sessions.
• Track the average login time, or loading times per device model.

HOW TO DEAL WITH THE LOSS OF TECHNICAL QUALITY?

WRONG STRATEGY #1: TRY TO AVOID IT COMPLETELY

In order to avoid the loss of technical quality, some teams choose to focus on a very slow development rythm and deliver content only if they’re completely sure it’s bug free and extremely polished.

While this sounds good in paper, in my experience wanting to release something only if it’s 100% perfect makes you uncompetitive, unreasonably slow and ultimately not able to release at a fast enough pace to keep your players engaged. So you’re may not be fullfilling player desires.
On top of that, even if you’re extremely careful, bugs will still appear, so the problem is not completely avoided.

WRONG STRATEGY #2: IGNORE IT AND GO BERSERK

Aggressively advancing without taking technical debt or loss of technical quality can be tempting, because the team will have the impression of fast progress and a lot of work done. But it’s wasted work. The players will not benefit from most of that work, and you will erode their confidence in your product.

The motto move fast and break things might be great for a fresh startup. But on the real world, and in particular on games that have reached maturity and want to establish a long term relationship of trust with its players, becoming a product with lots of crashes, bugs and bad performance it’s a NO GO.

WRONG STRATEGY #3: REGULARLY STOP EVERYTHING AND FOcUS ON FIXING

Another strategy to keep bugs and loss of tech quality at bay is to stop regularly the production of new content and solve all the bugs. While this might be the only option if the issue has reached a size that drastic actions it’s required, it isn’t a very effective way to deal with the problem.

This strategy means that the quality perceived by your players will be bad, since the game will fluctuate between long periods where it doesn’t work well, and short spans of time where it does (but there’s nothing new to enjoy)
On top of this, tech tasks is something that can generate endless amounts of work: no matter how many bugs and optimizations are done, there’s always more to be done. It will never reach a point where a game is completely bug-free and perfectly optimized.

THE RIGHT STRATEGY: BE CLEAN TO START WITH, AND CLEAN PROACTIVELY

In my experience, the proper way to deal with the loss of tech quality is:

• Try to keep a high (but reasonable) tech quality standard: This means integrating in your development process that the devs QA their work, making that the features and releases are QAtested by a dedicated team… and in general making sure that what is released works fine, within reasonable time constrains.
  
• Have a constant and proactive investment on keeping tech quality high, bugfixing and quality-of-life features, focusing on high impact elements and adding some not prio elements into the mix.

3 TIPS TO BOOST THE TECH QUALITY

Here are 3 good practices that I’ve seen work very well on my past projects, and which can be performed in paralel for even a greater win:

• 1/ Hack Fridays: Allocate one day per week on the entire team to work on Quality of Life features, Bugfixes and technical related projects. Fridays are particularly good for that, since it’s a day that has lower productivity than usual.
  And having a single day will help the team focus on high impact – low effort stuff.
  
  
• 2/ Revamp as a Feature: Whenever a new feature is delivered which touches a system that can be improved, do a small detour and solve technical debt, apply quality of life or just revamp the whole thing from scratch. Problematic features are probably the points of the game where there is most opportunity.
  If you plan ahead enough, over time you can do a review of a lot of the core.
  
  
• 3/ Firefighter Squad: Assign a group of devs tasked with dealing with technical emergencies as a sidejob. They’ll work as usual but if something starts burning they’ll stop whatever they’re doing and go fix it.
  Not really the best solution, but at least will keep showstopper bugs at bay without disrupting the entire team, and improves your reaction capacity if problems arise.
  
  Optionally, if the technical maintenance of the game is critical (highly competitive, multiplayer or MMO game…) or the status of the tech quality is really bad, the firefighter team can be made a permanent.
  In my experience, this works nice as well, but has the strong handicap of having to dedicate developers exclusively to these tasks.