Bruhvinskii 👾

I do not work for Activision, but have years of award winning software development work on my resume, some of which people reading this probably use today. My experience is in both Product and QA, for multiple companies large and small. Here are my insights, using plain language as much as possible: A 3 year project, from the top level, would look like this: Year 1: Planning and foundational development. Why do we need a product, what will it be, and who will we sell it too? This is the time for market research, customer analysis, etc. Stakeholders will draw up a design document, that outlines what the product will be, what basic features it will have etc. Back end engineers will start laying out the framework code and building wireframes. Year Two: The design Document will be *finished* and engineers, designers, PMs, etc will be assigned to various aspects of the product. During this period you go from concepts and wireframes to fully functional builds. Design also starts building / implementing the final look and feel of the product. Icons, textures, etc all get developed here. QA starts to get involved here, checking the functionality of what's being built. Marketing starts spinning up, and an internal release date is usually set. Year Three: The UI, textures, etc, all get applied and the finished product takes shape. QA starts getting its hands on more complete builds. Marketing starts working with press and partners early in yr3. The closer to launch you get, the more resources get brought in to finish it and get it out the door. With that summary out of the way here are the biggest insights I can give to some of the points @iamExpel and others raise. The core ideas behind what Warzone 2 would be were likely created between S5 of MW2019 and the first half of BOCW. Once the decision to make a WZ2 was made, they likely looked at the things that worked well in MW2019 WZ1, and wanted to lean into those while trying to add more to the experience. Late MW2019 Warzone played so different than Late Caldera WZ, but WZ2 would have already been too deep into the dev cycle to change. Why didn't WZ2 ship with XYZ feature that Caldera had? Most of the QOL features people loved in WZ1 arrived very late in the Caldera life cycle. If you overlay a 3 year dev cycle, Balloons didn't hit Caldera until late in the WZ2 year 3 cycle. By the time Product had enough data to determine how effective / liked / used they were, WZ2 was likely within the latter stages of the launch cycle. The idea just came about too late for launch. Why don't they just delay it? Oh man, this one right here is where people don't truly understand what launching a major product takes. Here's why a product like COD isn't going to push back a launch day for anything: It would ruin the launch and likely cost Millions, if not Tens of Millions. So here's what goes into a launch: Obviously the game needs to be done. Packaging / printing for hard copies. Ads, both digital and physical. Partner relations Press / Reporters Content Creators COD is big time, they don't just do gameplay render ads: The coordinate with brands, they do full on commercials, billboards, crossovers with other brands etc. To coordinate all of that takes months, but that's not the biggest issue: They are asking partners, ad sellers, other companies, press, and others to reserve days and weeks for this content. Reporters need to block out time, Partners need to create special packaging and hold off other campaigns, Ad sellers need to reserve billboard space, TV slots etc. All of this is secured by $$$. If Activision cancels a 2 week ad campaign, everyone involved loses money: Ad sellers have empty billboards, Mt Dew has boxes and cans and standies that are dated and go down as a loss etc. These slots are reserved with deposits, Activision has so much money on the line, pushing back a launch is not in the cards. Why don't they just add more devs? Software is incredibly complex. Simply adding people isn't usually the best answer to improve quality, because of the sheer amount of catchup a new person needs to do. Time is lost bringing people up to speed, and fixing the inevitable new issues created b/c the added devs don't have the full grasp of the project's change history. It's one way fixed bugs get re-introduced. Why don't they fix, upgrade, change the servers? For online systems, depending on how they're built, it can be like replacing the motherboard on your PC. yeah, you can do it, but there's no guarantee its plug and play. You might end up having to fix tons of software issues and even replace other hardware bits like the case and do basically a complete rebuild. Given how many COD games are likely hosted on the same severs, switching them out might be just a nightmare nobody wants right now. Why does this thing get fixed in hours while this other thing take days or weeks to fix? Why aren't creators brought in to QA issues right before launch? Look, finding bugs, figuring out what *actually* causes the bug, fixing the cause, testing the fix, making sure the fix didn't break anything else, then deploying it is a process. The biggest parts are *actually* figuring out the root issue, and fixing it without breaking anything else. Finding bugs is easy, but being able to articulate what exactly the bug is doing, and specifically how to replicate it reliably is a talent that most people don't have the patience for. Bringing in a bunch of people like at *next* isn't going to help much beyond simply testing server strain, because the feedback is almost always going to be personal preference over objective analysis and if you actually have 150 people trying to absolutely crush the game, the odds that a bug one person experiences is actually caused by what another player is doing is pretty high. Things like that make the ability to ID the bug and replicate it extremely difficult. So many bugs likely seem like edge cases in testing, but become more apparent at scale in ways you just can't see in a QA focused environment. That being said, some issues are as simple as changing the number in a table (for things like item prices or weapon damage) while other, seemingly simple fixes can have so many thing interconnected to what needs adjustment that a bigger test is needed. Why doesn't anyone listen to the customers? This is the hardest thing, as a developer, to deal with. Customers, especially ones that love the product are very passionate. They're also often the biggest power users and often drive opinions on what should or shouldn't be done. Unfortunately, in my experience, catering to this more often than not creates a product that doesn't appeal or is too complicated for non power users. This ultimately hurts adoption and usage rates. I remember building products pushed by these power users, and they loved them. Everyone said it was great. But when looking at the actual real world data, the adoption rate would be somewhere in the 2-5%, rarely justifying to costs to make. Going to stop here, I've got so much more to say, but I'm running out of twitter words and likely out of people reading this far anyways. If anyone's interested in more details, I'm happy to dive deeper.