Halo: The Master Chief Collection was a great idea, with poor execution. I have already ranted about various problems here, so that I can take a more level headed approach to this post. The goal of this post is to provide constructive criticism that I believe should be applied for future Halo releases.
My Background On Legacy Code Maintenance
The opinions that I am going to express in this post are thoughts that I have gathered through my own software development experience. I have worked with multiple code bases that I did not write, multiple different managers, and seen how the business side of my employer works. Through those experiences I have taken note of problems that I caused, and my collective team caused, that I think map pretty well to things we have seen in Halo: The Master Chief Collection. No one is perfect, but we also never improve if we sweep problems under the rug.
For the programmers - Take more time to learn your codebase.
Working in code bases that you did not write is a hard thing to do, and making all of those code bases work together is even harder. This makes Halo: MCC a very difficult problem to solve. Not only are you trying to adapt all of the individual games to use next gen APIs, but you are also trying to wrap them all up into one seamless experience.
Early in my career I had the opportunity to work on a similar setup. The technology was iOS, we had six apps, using one framework, and my team was supporting/improving all of them. Most of us were newer devs and none of us had been there for all of the app development. Over the next year I learned just how tough it is to manage and expand a codebase that was not your own. In the end I walked away with one rule. Never make a change to a system that you can't fully explain to another person.
I learned this lesson the hard way, as I would imagine many of 343's developers are learning now. Nothing is worse then when you make a change to one area of the codebase and it breaks a seemingly different part of the codebase. This happened to my team more times than I can count, and it almost always stemmed from not understanding exactly what was happening in the code. The tough part about this is finding time to learn the code when superiors do not understand why something is taking so long. My suggestion is to be upfront and honest about how long it takes you to learn. A good manager will understand that this time is needed. A bad manager will not. Ultimately I am much happier to tell my manager I will need more time, then see my code fail out in production.
For the Project Manager - Protect your developers
There was a subtle but profound truth in the paragraph above, a good manager understands when things take longer. I believe this to be one of the central roles of a project manager is to be a fair translation between the business of a company and the developers. The business says what it needs, and when they want it. The manager translates this into manageable pieces for the dev team. The dev team communicates progress back up to the manager. The manager works with the business to figure out what to do.
In simple words this does not sound too bad, but we all know that each layer of this process piles on the stress. Good managers know how to handle that stress. Most managers do not. The key here is transparency. Transparency is not shifting blame. Transparency is not hiding bad news to make the business happy. Transparency is being honest when bad things happen. If the devs are falling behind, be honest with the business. If a developer is struggling, come beside them and give them support.
This obviously has limits. Sometimes developers need to be let go. Sometimes the business needs to be told it can't be done. You get paid the big bucks to make those decisions.
For the business - Even the best laid plans can fall apart
The business is all about money, and thats the way it should be. Honestly, thats their only job so if its not about the money then you aren't doing business. Now lets take a look at the business of Halo: MCC.
The MCC idea is simply gold. Package up four of our favorite games, bring them to the new console, and sell them all for 60$. Wait there's more! This was a great idea for selling consoles. It was a great way to deliver the Halo 5 beta. It was a great way raise hype for Halo 5 in general. Most importantly it was a great chance for 343 to recover from Halo 4.
For all of these reasons it is easy to understand the struggle they must have gone through when weighing out whether or not to delay Halo: MCC. For what its worth, I wouldn't have wanted to make that decision. Its also tough to retro-activly make this choice, because I'm sure that no one thought it would be this bad. However, it is this bad.
The real question that I would have asked myself when trying to make this choice is whether or not you gamble with the Halo franchise. The easy answer here is no. You don't take any chance at ruining something that when handled correctly should yield at least three more games. The reason you don't gamble with it is because many of us Halo fans already felt a little used. This was supposed to be the redemption game, and I fear that a lot of us won't be betting again.
Kenny Rogers said it best: "You gotta know when to hold 'em know when to fold 'em". I can't blame the business for making the choice they did, I may have done the same thing. Now they have to be willing to take the heat when fans don't just roll over and take it.
So Who am I mad at?
I have tried over the past few sections to be fair and level headed. Now is the time for a little rant. I described three different rolls in the software development process. The truth is that each one of them deserves some blame, but at least one of them has failed beyond understanding. Either the developers have written too much bad code, and can no longer fix things. The manager was not transparent and failed to lead. Or the business had unrealistic expectations and couldn't make the tough calls to delay the game.
In any or all of these cases, Halo has been tainted, and is no longer what it once was.