Microsoft can only contract workers for 18 months before either:
A-letting them go (and possibly rehiring them again in 9 months again with no benefits, if the worker was even interested at that point)
B-Renewing their contract and paying them benefits or;
C- hiring them as full employees (which also means paying benefits)
The biggest reason for Infinites struggles has been the lack of continuity in the workforce as the engine for the game takes a long time to get familiar with. Because their option has been to let employees go and hope that they maybe come back this has led to a hamster wheel struggle of training employees on the technology and letting them go before benefits must be paid. Once old contracts expire and the new ones are left to pick up the pieces this often can delay the process if completing projects as they may need to re-do some things or change the goal of that project alltogether (however big or small that may be). If you cannot sustain a regular workforce, how can you expect to support a game long term?
This is not to say that contractors are unusual in the industry or that there aren’t times where you may need to hire temporary labor to get a project done, but supporting a live service game needs to have some core set of devs to provide continuity and direction to the game which are both things that Infinite has been lacking.
We as a community need to be making our voices heard that Developers need to be hired on full time instead of allowing their contracts to keep expiring. This would both alleviate the constant pressure on the devs by allowing them to not be stuck picking up the pieces every couple months as well as providing them better security. If priority zero is meant to preserve developers healthy work/life balance they need an environment where they are not constantly being put under pressure at work and wondering what happens when they cant get their contract renewed
At this point the only way to get this to change is to make this as public as possible to force Microsoft to change, otherwise this game will die.
Tl;Dr stop saying the Devs are lazy and start calling Microsoft Greedy. The more public embarrassment for the company and the less people that are enticed to work there the more open to change they may be.
EDIT: Just some more fuel to the fire, The reason that there is the perception that the devs are blaming the community is intentional. It is to divide the community and the devs to get us to attack each other when we all just want the game to be good. Again, put the blame where its deserved: AT MICROSOFT
3 Likes
Working in/with software, at a big company with similar hiring practices, the hiring of contract workers is generally done during feature development, architecting, and implementation phases, not during sustaining. Sustaining is post-launch, generally what most folks would consider the “live” portion of the software’s lifecycle. Headcount requirements for development/architecting/implementation are higher than for sustaining.
The current dev shortage at 343 is not because of the fact that they hired contract workers and their contracts were terminated/ended when the feature was done - there is a dev shortage, IMO, due to the fact that 343 was ready to be in a sustaining cycle right now, and not rearchitecting systems and implementing new features. 343’s sustaining team is not large enough to tackle rearchitecting + new feature development + live content. Basically, there would be enough devs on hand to do live things, but not live things plus all of the back end work that needs done given player feedback. Your UI rearchitecting, Spartan career progression, challenge system overhaul - all of these things fall outside of the realm of sustaining work.
Now, according to 343’s socials/community folks, they are hiring to overcome this gap and get to the point where they’re in a sustaining rhythm. End of the day though, the community perception of the contractor thing is a bit off. Software dev has distinct phases, and basically launch went sideways enough to where we moved backwards through phases, necessitating a ballooning of headcount to handle that work.
2 Likes
I appreciate the insight, just a couple things though.
Of course they say they are going to hire more people, theyve been in the same loop ever since they started development.
While you work at a company with similar practices, I have known several people that have been in-and-out working at different departments at Microsoft. When the same people keep being brought back into the same department because the separtment needs their talent but their managers cant convince the higher ups to let them stay even though they say they are needed (hence the multiple rehirings) this is indicative of a wider hiring-policy issue at the company that needs to be addressed.
My company does the same thing - we contract out to contracting firms for development on iterative software releases. Usually it’s the same people who work on each release, just on a contract basis - so similar sounding to your acquaintances’ experiences. The business reason for this is simple - the time between hirings, that headcount is underutilized. It’s better to hire them only when they will be fully utilized.
For example, let’s say you release software on a yearly basis. V1.0 was developed with your mix of contract devs and full time devs. 1.0 launches, and your contract workers’ contract is not continued. Your dev cycle for 2.0 begins immediately, with some of your team on sustaining work. The rest of the team designs the specifications for the features coming in 2.0. This takes 6 months. After 6 months, you’re ready to begin implementation and testing. You now re-hire your contract workers, work with the non-sustaining portion of your dev team to implement the 2.0 features, and then release 2.0 a year after 1.0. Then, you drop the contracts and repeat. Those contractors are likely the same as worked on 1.0, their skills are needed to do 2.0, but they’re only needed for 6 months. Rest of the time they’d be wasted resources. Edit: I do think it’s worthwhile to note here that, in complex cases, you can have multiple teams at various stages of this cycle if the software is complex enough, or the company is large enough/complex enough. It does happen that different teams can be on different parts of the lifecycle and contract workers can basically shuffle back and forth between teams as well, with a short gap between each hiring, depending on what you’re coding and if their skills are applicable.
For 343’s case, basically, their 1.0-to-2.0 cycle, to continue the analogy, seems to have been aiming to be long enough, and the 1.0 release stable/complete enough, that the sustaining team could have handled most of it mixed in with their live updates. Obviously, this has not worked out. Thus, they are moving back to the designing/hiring/implementing phase of the cycle.
2 Likes
Contractors are probably not as big a deal as you think. The real big issue plaguing Halo is management vision/direction. 2-3 years of wasted time after H5 trying to turn Halo into a hero shooter. Bonkers.
2 Likes
FYI, a (former?) dev clarified the hero shooter thing:
Robeytech on Twitter: “@b_hydb @ChrisRGun @ManwichBahama Well I worked and shipped the game. So there is no leak. We prototyped a bunch of stuff as we worked on the game which is never wasted time. But the way it’s being spun is super inaccurate. It was in the time allotted for the game to go through those design cycles.” https://twitter.com/robeytech/status/1518225452334305283
1 Like
I’m aware, and I completely disagree. Those “design cycles” as he put it are the exact time wasting nonsense that put the game in its current state. It’s just a poor justification, a copout.
If they budgeted the time, it generally wouldn’t have impact on most of the issues facing the game, IMO. Desync is a server/engine bugginess issue not impacted by MP gameplay design prototyping, UI architecture (number of playlists supported) is a design specification issue not impacted by MP gameplay design prototyping, the BP and challenge system could theoretically have been impacted, but it’s hard to know one way or the other without knowing specifics of how the hero shooter prototype was implemented, to what extent it was explored, and at what stage the design prototype was done.
Pretty sure those design cycles weren’t wasted, overall - I mean, they didn’t settle on a hero shooter, which one could reasonably assume was a result of the prototyping not producing good results, and thus influencing the game towards a more traditional gameplay loop/system.
IMO, the reason for game’s current state is that they anticipated (incorrectly) that people would go with the F2P-originated limitations on the MP because it was free. Limited playlists, a smaller feature set, and heavily monetized are all hallmarks of F2P, but the tradeoff being you don’t have to buy anything. People didn’t jive with the limitations, and here we are - waiting on limitations to be removed or reworked, bugs to be fixed, and monetization to be ungoofed. A gameplay prototype that was done during an unknown period in dev that was ultimately rejected likely had no influence on these things.
So in that regard, IMO, he’s right - it isn’t responsible for the game’s state. Other decisions are, and fundamentally it’s that the decisions were just ones that people didn’t like. Couple that with a slew of bugs that come from a new engine iteration running on a multitude of hardware variations - including new server-side software, and you have the recipe for Infinite.
2 Likes
You got a source for that claim?
2 Likes