Keeping with the ELI5 idea for lots of reasons, mainly for the sake of bad analogy.
First some credibility, from my post below.
Does a cook, who orders a meal at a restaurant, have to be in the kitchen while his meal is prepared to KNOW it was cooked incorrectly? No.
Just as someone who, like my self (more akin to sous chef, or burger boy) can tell there are some serous technical issues with MCC code, and how it interacts with MS and 343 Servers. The evidence?
If they could of fixed it by now they would have fixed it by now.
That above statement says alot about how the code is written, maintained and functions.
to ELI5;
Think of software working (I must be hungry) like functions restaurant.
You have lots of restaurants, some good, some bad, some just OK.
So what makes a restaurant good? Lots of things to lots of different people.
For example:
I love a dive bar near my college because I can get a whiskey and a beer for four dollars. (they serve food also - I have not had nerve to try it yet)
My friend would never step foot in the bar because it is dive even for a drink. Its dirty dark, possibly unhealthy to be inside of. My friend prefers the place up the street and is willing to pay the extra cash for the same drinks.
Whats the point then?
The point is people like restaurants, good, bad and ugly, for different reasons.
So we need to abstract out what makes a restaurant good. In other words: what never changes when your assessing what makes a restraint good almost all cases?
The food. (MCC)
While I am only using drinks as an example above, the drinks I get at the dirty dive bar are the same brand / product my friend gets at the pricey place.
If a restaurant or any business (the makers of my favorite drink) follows "known best practices" in their industry then they have strong chance of having a good product.
If they do not follow "known best practices" then chances are the product will suffer.
So if you ran a restaurant like you designed good software, it would be a very bad restaurant!
You would need at least two waiter/waitress for each table.
One person could only do one job. Never more, never less as much as possible.
Front of house...
You would need one busser to come to set your table.
You would need one waiter/waitress to come to take you to your table.
You would need one waiter/waitress to come to your table and take your order.
You would need a different waiter/waitress to come to make any changes to your order.
If you had any questions about the menu you would need a different waiter/waitress to come to your table to answer any questions about the menu.
You would need another busser to get your table.
You would need one person to tell you your bill.
You would need one person to take your payment
You would need one person to take print your receipt.
etc...
In the kitchen...
The cook would be a different person for each thing he /she does...
You would have one person that puts salt on dishes. That is it. You would have one person that flips items on grill. That is it You would have one person that puts things on the grill. You would have one person that takes items from the fridge. You would have one person that puts items into the fidge.
etc...
So if you had a salt issue. You know exactly! what to fix! where the problem is coming from, and how to fix it (hopefully)
So in the case MCC and team balancing (3v4) instead of (4v4)
In theory there should one (person) method that deals with getting this set correctly, so that in the case of it was not working correctly, you could simply fix it. This is clearly not the case with MCC.
I hope that makes sense. Feel free to ask any questions.
If you want to learn more google search about:
object oriented problem solving and design
low coupling and high cohesion
completeness
primitives
modularity