Search

Tuesday, February 18, 2020

Ending Video Game Death Marches - #1 Managing Debt



We’ve all experienced it: A sink stacked high with dirty dishes. You rarely have time or incentive to tackle them. Usually, you’re in a rush to do it before a visitor arrives or when you run out of clean dishes for your next meal.

Eventually, most of us learn that washing the dishes once a day (or at least throwing them in the dishwasher) is a better approach. It takes a little discipline to get into the habit…similar to flossing your teeth every day, but it’s for the better good.

The same principle applies to game development. We often let the crud in our games pile up. We call this crud debt. We often push off paying that debt until it’s an emergency, and that usually leads to crunch, and lots of crunch sucks.



Why Debt contributes to Crunch (getting stuck between a rock and a hard place)
Debt is unfinished work, whether it’s bugs that need fixing, stand-in art, or untuned mechanics. It’s called debt because, like financial debt, it has an interest rate whose payback grows over time. Debt piles up —usually inside some tracking software—where it stays, growing until some point in development, commonly called alpha (the “rock”), when teams dive in to address it. The problem is that alpha is close to a ship/deployment date that is fixed (the “hard place”). Teams quickly discover that there is not enough time to address all that debt, and management decides it’s time to crunch.
It Often Gets Worse 
Ironically, managers usually react to crunch, low quality, and missed deadlines by demanding more detailed task planning. This tends to squeeze out the slack that should be used to address emergent debt. That slack is essential; when was the last time you estimated the amount of work it took to fix a bug that hadn’t been found?

Setting Aside Time to Manage Debt Works, but it’s Not as Easy as You Might Think
It’s easy to see that if you have less debt, there’s less reason to crunch because of it. So what’s so hard about managing debt?
There are two significant reasons that we fail at managing debt. First, it seemly slows down development. Practices like unit testing, creating automated test tools, and making sure new features introduce minimal debt takes extra time upfront, but in the long run, it saves a lot of time. However, it’s often hard to convince a stakeholder that doing the extra work now is a lot less expensive than doing it months from now.
Second, we developers can be lazy. Yes, I said it. Managing debt, such as optimizing polygon usage, replacing stand-in audio, or refactoring code that has gotten “crufty” is a lot less fun than tossing in something new. Like washing your dishes daily, it’s less fun than making them dirty, but it’s a discipline that needs to be built up to avoid the piles in the sink.

Where to Start
Debt is best managed by setting aside time to eliminate levels of it. You can start by establishing an agreed-upon time that’s set aside to address debt. For example:
  • Every day, eliminate any problems that cause the game to crash or otherwise be unplayable.
  • Every Sprint, make sure the game is demo-able to internal stakeholders. This could mean that the frame rate is stable and fast, and players can have fun.
  • Every Release or milestone, make the game worthy of showing the outside world. It could be missing key features, like a marketing demo, but what is there is polished.
How to Master It
  • Build test automation. The Gear Up book describes several useful ways automation can help
  • Metrics. There’s a lot of debate about whether tools that measure code quality, like unit test coverage, help. I feel they do. If you can measure something useful, you can improve it, but beware of the metric becoming the goal.
  • Educate. Try pair programming. For example, hold a “Wednesday Pizza Talk” (Gear Up) to educate developers about practices to reduce debt.
Learn More

No comments: