This is MS we are talking about - many have been critical of their QA when relatively simple one development path. To have TWO development teams at different stages will definitely lead to Left Hand not knowing what the Right Hand is doing or vice versa - you are obviously more confident about the management ability of MS than I am - lol.
I'm noticing the Microsoft Family icon showing in the notification area on the taskbar with this build even though I'm not in a family group.
No process is running for it, and the icon doesn't do anything when clicking on it, hovering over it, or right clicking on it.
Restarting the explorer process sorts it though.
On my computer, it is in the hidden area of my taskbar - along with Skype. So not displayed.I'm noticing the Microsoft Family icon showing in the notification area on the taskbar with this build even though I'm not in a family group.
No process is running for it, and the icon doesn't do anything when clicking on it, hovering over it, or right clicking on it.
Restarting the explorer process sorts it though.
I disagree somewhat. Suppose Team L rewrites some code to do L stuff and Team R rewrites same code for R stuff.
When R and L merge, they will get all sorts of bugs arising from this and spend ages sorting it. On the other hand, if they worked together, things would be a lot smoother.
BTW - I am talking from personal experience on this from my software development days - LOL!!
It is basically the same as two people working on a report independently and not communicating - a blooming nightmare!
@cereberus
That is what software engineers and lead programmers are for. You have a set of features that need to be implemented. Those features are then converted into APIs and specifications. At this stage there only exists a skeleton that does nothing. Now one programmer can take a single feature and make that API work according to the specification and another programmer can take another feature and focus on that. Neither have to ever worry about what the other does because the specification is already in place. The features are already separated by design, so there is a minimal risk that they will conflict once they merge into one code base.
This is how I've done it and rarely have I had any issues. Although sometimes it is possible there exists a bug that can only be detected at runtime in a very specific workload. But this is what beta testing is for.
I'm not assuming, I know. Why else would Windows contain about 200k files? Just to have all files do the same thing?
Besides, this is exactly what MS promotes themselves.
Edit: One example: Anyone ever wondered why there are sometimes running 10-25 RuntimeBroker processes at the same time? That process does a lot of things useful for many applications.
Quote
