Paradox of Prosperity: A Hit Mobile Game’s Initial Success Eroding Into Long-Term Paralysis- Part 1

A cautionary tale of a top-grossing mobile game struggling to evolve from a nimble start-up game team to an adaptive enterprise-scale service.

Discover how top-grossing mobile game teams face and overcome the challenge of evolving from startups to sophisticated service organisations, ensuring their game's success and adaptability.

Learn about the dangers of prioritising quick fixes over sustainable code development in mobile Game-as-a-Service, leading to technical debt that can hinder future growth and innovation.

Explore strategies for managing technical debt and prioritising technical value over functional value to ensure long-term game service success and adaptability.

This series split into two sections, dives into a frequent challenge I have witnessed with top-grossing mobile game teams. In the first instalment, we’ll delve into the elements that affect a game team’s capacity to fulfil delivery expectations and adaptability as they evolve from a nimble startup to a sophisticated service organisation. The second part outlines steps you can take as a producer to prepare your game for the future, guiding it through its growth from a global launch to large-scale live operations.

Although this cautionary tale focuses on mobile Game-as-a-Service, much of the problem and solutions can be applied to any game development endeavour destined to become a commercial success as a service.

Part 1- Lighting in a bottle

Nailing a top-grossing mobile game feels like catching lightning in a bottle—utterly thrilling and somewhat miraculous.

Picture this…

You’re part of a nimble crew, tirelessly chipping away at prototypes and minimum-viable products. Your aim? To quickly roll out your game, eager to see if the numbers hint at a success big enough to warrant a serious splash in user acquisition spending.

Caught up in the development storm, your eyes are firmly fixed on that global launch milestone, barely letting yourselves think about what lies further down the road, say two or three years from now.

Amidst the rush to cross the finish line on time, there’s a chance you and your coding comrades might value quick fixes over crafting tidy, organised, and well-documented code. Your squad, laser-focused on nailing the here-and-now of the game’s workings, might overlook how it will stand up to the test of time—adapting to growth or pivoting in response to new demands.

And then, WHAM! Your game is a smash hit, your core loop is sticky, daily active users skyrocket, and players are converting. It’s like money’s raining down from the heavens.

So, what’s the game plan now? Priority number one: keep your players hooked. Roll out fresh content, new features, and exciting events to keep them returning for more.

At this point, the notion of diving back into the code for a significant overhaul and scaling up for big business? That’s the furthest thing from your mind.

Fast forward a few years…

Now, your once small team of scrappy game developers is a multi-million dollar business with a hundred people working on the game. The developers who were there in the fast and loose times are long gone to new pastures. Their replacements have their hands complete with spaghetti code and little documentation. The demand of the business to deliver more and more. So, the developers just kept building on top of that original MVP code that was never intended to be used at an enterprise scale.

The result…

Game features that would have taken weeks before the game blew up now take months. Changes that appear simple to outsiders are much more complicated under the hood. There is old code that no one wants to touch with a ten-foot pole. Adding more developers validates the Mythical Man Month. Onboarding new team members is a nightmare that takes much longer than it should get up to speed. “If it ain’t broke, don’t fix it” becomes the mantra. Ambitious stakeholders want more, faster and NOW!

Then, there’s the mental toll. The weight of technical debt can crush spirits and fuel frustration. Developers cherish their craft; wrestling with chaotic code saps their spirit. The struggle extends beyond mere hours spent on enhancements or repairs. It touches on their professional pride and their joy in creation. Burdened by technical debt, teams might find themselves on a fast track to burnout, their engagement dwindling. This, inevitably, dims productivity and tarnishes the quality of their output.

Then, the finger-pointing happens. The product folks begin questioning the development team and their ability to execute. The development team becomes resentful because the roadmap planners deafens their concerns about tech debt and the need to refactor to improve delivery. Senior leaders unable to grok the rook cause blame everyone on the team and then step in to save the day with a sledgehammer.

I have repeatedly witnessed this phenomenon in mobile game development across multiple studios. I have been involved in laborious modernisation efforts to correct these problems, which have cost millions. I have found myself in a role akin to a crime-scene investigator performing forensic examinations to uncover the perpetrator and the accomplices too many times.

All this can be avoided…

Potential root causes

Based on my anecdotal observation and root-cause analysis work in studios suffering from this phenomenon, the common denominators of this dilemma are twofold. The first is a misunderstanding of technical debt, and the second is the perils of prioritising functional value over technical value.

What is technical debt?

Technical debt means choosing a quicker, often less ideal solution to achieve an immediate goal, like launching a feature or hitting a release deadline. It is frequently described metaphorically as taking out a loan for a quick financial boost with the idea of paying it back later. An advantage of this metaphor is its effectiveness in simplifying the concept for those without a technical background, making it easier to understand.

British software developer, author, and speaker Martin Fowler suggests technical debt can be categorised as quadrants: reckless to prudent on the x-axis and deliberate to inadvertent on the y-axis.

As in life, debt can be classified as either reckless or prudent.

A reckless debt results in crippling interest payments or a long period of paying down the principal. Reckless technical debt occurs when decisions are made without fully understanding the consequences, often under the guise of expediency. It’s the coding equivalent of “we’ll fix it later” without a clear plan for how or when. This can happen due to pressure to meet deadlines, lack of knowledge, or a culture that values speed over quality.

A prudent debt may result in gaining material benefits and not being worth paying down if the interest payments are sufficiently small. In development terms, this could mean choosing to implement a feature in a way that’s not perfect but gets it out to your players faster, with a solid plan to refine and improve it in future updates. You’re borrowing time or resources now, with a clear strategy for paying it back.

Technical debt is like a credit card for your codebase. Easy to get into, hard to get out of.

– Juan Jose Behrend

Consider inadvertent versus deliberate technical debt to add another dimension to this metaphor.

Inadvertent technical debt sneaks up on you. It could stem from poor technical design, a lack of understanding, or underestimating complexity. Typically, it arises from a team rushing to meet deadlines without thoroughly vetting the long-term impact of their decisions. This technical debt is difficult to plan for because it wasn’t part of the plan. It manifests as bugs, performance issues, or scalability problems that you discover only after they’ve begun to affect your game’s performance or user experience.

Deliberate technical debt is like taking a calculated risk. A decision is made with eyes wide open, balancing the immediate benefits against the longer-term costs. The key here is that the decision is intentional, allowing for strategic planning to address this debt in the future.

Read more about the technical debt quadrants.

Misunderstanding about technical debt

Technical debt is often viewed through a narrow lens, perceived by non-technical stakeholders as a strictly negative aspect of software development. This perception overlooks the nuanced and strategic role technical debt can play, especially in the fast-paced early stages of development. In reality, incurring technical debt can be a deliberate decision to prioritise speed and innovation, allowing teams to prototype and iterate on ideas rapidly.

Tech debt is inevitable; you may call it ‘integral’ to game development. While you’re programming, you are learning. “Finding the fun” in game development involves iterating on game mechanics and features based on testing and feedback. This iterative process often changes the game’s technical design and code, contributing to tech debt.

The critical misunderstanding lies not in the existence of technical debt itself but in the approach to managing it. Thoughtfully incurred debt, much like financial debt, can provide leverage if recognised early, managed wisely, and repaid reasonably before the interest—in this case, the cost of future changes and maintenance—becomes untenable.

Ignoring these looming obligations means minor issues can evolve into significant obstacles, hindering new feature development and slowing innovation.

Left unchecked, technical debt will ensure that the only work that gets done is unplanned!

― Gene Kim

What is functional value and technical value?

When we dive into Game-as-a-Service, we encounter a variety of value metrics that help stakeholders understand the impact and importance of their efforts. Two such metrics are functional value and technical value.

Functional value is all about what the game or feature does for its players. It’s the practicality and utility that the end-user experiences directly. Think of it as the “what” of a game, feature or event. It answers the players’ needs and problems with tangible features and capabilities.

Conversely, technical value might not be directly visible to the player but is crucial for a game’s long-term success and sustainability. It encompasses the quality of the engineering and technology behind the game. This includes code quality, architecture robustness, scalability, security, and maintainability. Technical Value ensures the game can evolve, adapt to new requirements, and maintain reliability and performance. It’s the “how” behind the game, supporting the delivery of functional value.

Perils of prioritising functional value over technical value

A game can satisfy players’ immediate needs and boast high functional value. Yet if it skimps on technical aspects, it might be riddled with bugs, hard to scale, or challenging to update with new features.

This oversight can create a deceptive saving, where long-term drawbacks soon eclipse the allure of quick wins. The actual cost is a gradual decline in the team’s flexibility to embrace change, innovate, and enhance gameplay.

A game packed with features but resting on an unstable technical base can turn into a maintenance nightmare. As the code grows more complex, tweaking it without causing more issues becomes a Herculean task. This complexity can inflate costs and slow the pace of responding to market shifts or fixing bugs.

If a game excels in delivering what players want but falls short on technical solidity, scaling up could become a hurdle. Performance might lag under heavy usage, extending the system for more users or content could be problematic, and rolling out new features might drag on. It can impact business performance by having poor user ratings in the app store or ANRs (Application Not Responding), impacting app visibility and discoverability on some platforms.

The underlying issue is a common misunderstanding of technical tasks. Non-technical stakeholders often see them as mere filler activities for developers, just some paperwork sandwiched between the “real” work.

Moreover, non-technical stakeholders usually underestimate the importance of refactoring, the consequences of technical debt, the necessity of technical documentation, and why code might not be fit for live production use. Consequently, efforts to bolster technical quality are either overlooked in budgeting or missing from product roadmaps.

Ironically, these same stakeholders often clamour for quicker releases, significant updates, and heightened quality, not realising the contradiction in their demands.

Agree or disagree? Please leave a comment.

In part two of this post, we will explore tactics to help mitigate the impact of this cautionary tale. We will advise production professionals how to avoid these potholes if they are early in their game’s lifecycle as they hold their mason jar open for that lightning bolt. We will also explore how those accountable for delivering a game service that is long in the tooth can rejuvenate their ability to adapt to change and deliver faster.

Special thanks to my unnamed former development partners who helped this “non-technical stakeholder” validate my assumption and ensure I represented this topic on their behalf respectfully.