It’s just a small change! How often do we hear that we need to fix something? We need to add a small feature. We need to tweak something. Code-wise or publishing, just realized they need this for retention, or maybe an analyst brought the newest data, so now we have to add just a few lines to the code. They don’t affect performance or any other departments, I promise. And it’s just like 3 minutes of coder work - why not? Fast forward: they broke the “Buy” button on the front page of the store on release. Why does this always happen with small changes? Well, if we think about it, we don’t usually think about it. Let me explain: Designers think in features and user experience.Engineers think in whole systems.Producers think in tasks.Stakeholders think in business outcomes. And one small change is always perceived as something isolated and usually without everyone’s awareness. So, it is basically a cognitive shortcut. And that happens not because everyone is wrong or unprofessional. It’s because modern production systems are highly interconnected, so it’s impossible to know what could potentially be affected by anything - especially if you haven’t worked on this project for 15 years. What is modern production? I’m glad you asked! It doesn’t matter if you build games or a banking app - you don’t just have a pile of features and assets. You have an ecosystem for each bit of work: Art, Code, Design, UI, Marketing, Publishing (maybe even Project Management - wow, you are a rich developer), etc. And each one of them has its own infrastructure, pipelines, workflows, and shared assets. To simplify, it can be shared data schemas, builds, automation processes, UI bindings, and many other things. What’s wrong if I just make a small color change to one of the icons? Well, that means you spend 3 seconds changing a color code. Then you have to assemble a build. Then QA has to check your small change to confirm that you indeed changed the color. Then you have to assemble the build again, which should be in a queue with other builds in the waiting list. Then we have to update the server with your changes - oh wait, did you tell anyone about that? No? Oh, that’s great, because you just submitted your changes during the commit freeze, and now deployment engineers have to fix the CI/CD pipeline, and we have to postpone the release for 4 days because it’s Friday. And by the way - we have to communicate that to users because they were waiting for this new version, and some of them decided not to wait that long and removed your app. Whoops, that’s awkward. Sorry to hear that. That’s alright, I’m here to help you! Let me introduce you to Change Propagation Surface (CPS) - the number of systems, pipelines, assets, and workflows that a change must pass through before it reaches the player. Your change should not be estimated by its task size, like “1 hour of work.” Your change equals CPS × Coupling Density (the amount of work other departments need to do in order for this change to pass). Think about it this way: One small UI tweak touches no shared data - low CPS.
A gameplay rule change touching code, balance, design, analytics, player experience - high CPS. One small UI tweak touches no shared data - low CPS. A gameplay rule change touching code, balance, design, analytics, player experience - high CPS. Let’s go back to the situation where you want to change the color of the icon. Those 3 seconds of work would affect UI, builds, player perception, experience, and design. It might also affect color coding for accessibility rules, plus build assembling, and finally server updates. It’s high CPS - of course, if you didn’t sneak that change in without everyone’s awareness (I see that - drop it!). The same goes for asset swaps or changing a stat value: it affects memory, AI tuning, destruction logic, etc. Don’t do that unless someone from senior leadership said it’s low CPS - then just do it and see how it goes. You can apply this approach basically anywhere in production because it is not an abstract thing at all and can be estimated. For example: UI
Backend
Client code
Game design
Economy
Analytics
QA
Build/CI/CD
Marketing
Customer support
Live operations UI Backend Client code Game design Economy Analytics QA Build/CI/CD Marketing Customer support Live operations Each of these items counts as a plus 1 CPS factor. Subsequently, the more of the same “items” you touch, the higher the CPS number you will get. And with that information, you can create a small estimation matrix like: CPS 1-2 - Local changeCPS 3-5 - Cross-functional changeCPS 6+ - Systemic change One more time, the formula is: Impact = CPS × Coupling Density. Easy! Let’s see how it works in a real-life example: So your developer went on holiday and completed a math course on LinkedIn. And when he came back, he said that there is a more efficient way of calculating EXP. This change is “one line of code.” Okay, but after reading this article, you already know how it works in reality and that it touches multiple things: Game balance
Player progression pacing
Economy inflation
Battle pass progression
Retention metrics
Analytics dashboards
Marketing promises
Customer support load Game balance Player progression pacing Economy inflation Battle pass progression Retention metrics Analytics dashboards Marketing promises Customer support load That means CPS is more than 7. So now you see that even though the code diff is tiny, the propagation surface is systemic and has a massive potential outcome. In other words, if XP progression speeds up things like economy, availability of the content, battle pass value, retention curves, etc., you should know that even if the implementation takes about 10 minutes, the ripple effect can take weeks of work. Why does live service production make it worse? Because it is amplified by content being reused across multiple features, by telemetry and economy being tightly coupled, and by systems being persistent and often requiring backward compatibility. So, the real cost you pay for propagation lies in prolonged timelines, hidden rework, cross-team friction, technical debt, burnout, and eventually, people resigning directly or indirectly. Instead of thinking, “Oh, this is a small change,” we should probably think, “What systems does this change touch?” Think about this as infrastructure, not a feature, and always try to bring that to cross-team awareness. And if you are capable enough, try to estimate the surface area, not just this exact small change. **The whole point of my way-too-long introduction is that there is no such thing as a small change in production systems. There are only changes in misunderstood affected areas. And the more senior you become, the more your vision shifts toward understanding how this change will travel instead of trying to avoid the change altogether.

Why “Small Changes” Don’t Exist in Production Game Systems

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Blending Worlds: How to Integrate External IPs Without Losing Your Game’s DNA

Jitter Clicking: A Strategic Mouse-Clicking Strategy

10 Ways To Make Your Innovative, Game-Changing, Synergistic Website Stand Out In 2018

10 Use Cases for Using Laravel to Build Web App Development Projects

10 Things You Can Do Better While Working With Programmers

10 Prioritization Techniques for Agile Product Development

Blending Worlds: How to Integrate External IPs Without Losing Your Game’s DNA

Jitter Clicking: A Strategic Mouse-Clicking Strategy

10 Ways To Make Your Innovative, Game-Changing, Synergistic Website Stand Out In 2018

10 Use Cases for Using Laravel to Build Web App Development Projects

10 Things You Can Do Better While Working With Programmers

10 Prioritization Techniques for Agile Product Development

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps