One senior executive’s warning about escalating conflicts to upper management
One of my friends was contemplating ways that they deal with others who disagree with them at work and wish to escalate a decision to upper management.
I was reminded of one senior executive who explained, “If two of you can’t resolve an issue and escalate it to me, then you both have failed. You are two experts on the subject, asking for a final decision from somebody who knows nothing about it.”
“The one thing I can say with near-certainty is that both of you are going to be equally unhappy with me making the final decision.”
Light
Dark
16 comments
Oh, yes. I think everyone knows it. 20 years ago, Microsoft became famous for the fact that its managers never took sides. Rather, in the event of a conflict, they’d sit both conflicting parties down and help them form a consensus. It was around the same time that I also heard about the “Why manholes are round?” interview question, and how it originated from Microsoft.
I doubt that’s the case right now. These days, Microsoft program managers are famous for hilarious gaffes. For example, in one of the Channel 9 videos about .NET Core, Microsoft’s program manager for .NET, Olia Gavrysh, asserted that one cannot install two copies of .NET Framework side-by-side on the same computer! Funny; I was watching that video on a computer with .NET Framework 3.5 and 4.7 installed side-by-side.
this comment has been deleted.
She’s not wrong. You cannot have the .NET Framework 4.x series installed side-by-side. If you have 4.7.1 and install 4.8, then you only have 4.8.
And there are similar restrictions in the .NET Framework 3.5 where you cannot install 2.0 or 3.0 alongside 3.5.
With the later .NET Core series and now .NET 5 and beyond, you can have everything many versions of .NET installed side-by-side, even down to the patch level (but I think the default behaviour of the installer is to remove some prior versions, so as not to clutter the installers).
You’re right that you can have 3.5 and 4.x installed side-by-side, but the 4.x series has been released for over a decade, so the side-by-side rule hasn’t applied in that time, and it’s only ever been done for major leaps (.NET Framework 1.x > .NET Framework 2/3/3.5 > .NET Framework 4.x)
I’m afraid no amount of word-splitting on your part can ever so slightly legitimize her goofy speech. She outright claimed that if you installed a version of .NET Framework (say 4.8,) all .NET apps, including those built in on the other versions (say 1.1), will take a dependency on it and thus break! She went as far as saying that upgrading .NET Framework has always been a company-wide strife! She was promoting .NET Core and did hold back when it came to hurling dirt at .NET Framework, however technically inaccurate.
And of course, you are wrong: The .NET Framework 3.5 SP1 installer installs .NET Framework versions 2.0, 3.0, and 3.5 side-by-side. That’s because there is no such thing as CLR version 3.0 or 3.5. .NET Framework 4.8 encompasses all .NET 4.x release assemblies before it, down to the patch level. In fact, there was one bug in .NET Framework that caused incorrect generation of SHA-1 hashes. When the bug got fixed, the old apps that used the buggy version didn’t get affected, although their developers got compiler warnings.
“The .NET Framework 3.5 SP1 installer installs .NET Framework versions 2.0, 3.0, and 3.5 side-by-side.”
Thanks for letting me know. It’s a shame they didn’t keep that practice.
“She outright claimed that if you installed a version of .NET Framework (say 4.8,) all .NET apps, including those built in on the other versions (say 1.1), will take a dependency on it and thus break!”
Would you have preferred it if she said “all versions of the .NET Framework within the last 10 years”?
“She went as far as saying that upgrading .NET Framework has always been a company-wide strife!”
On the MS side: you’re building a big framework like this, can’t make breaking changes due to backwards compat, your component is a part of Windows so it needs many years of servicing.
On the customer side: you have a 4.5 app distributed to many users, then your infra team pushes 4.8 because they need it for another app, which in turn breaks the 4.5 app. can’t run them side-by-side…
Neither scenario would cause strife for you?
Neither would cause strife because they are your imaginations. And hers. I already explained why.
“NET Framework 4.8 encompasses all .NET 4.x release assemblies before it, down to the patch level”
That’s not the case – just imagine the file sizes that would require. I think the confusion comes from the fact that the SDK includes the reference assemblies for all previous frameworks to avoid the problems we had with 1.1 and 2.0 (i.e. the compiler being unable to decide whether your 1.1 framework app used any 2.0 features)
The framework does have feature switches for breaking changes and tries really hard to not break anything, but there are bugs both in applications and the framework that can lead to problems (e.g. performance improvements making a race condition obvious).
Due to this and simply the general reluctance of large IT departments to update global software if it’s not absolutely required, there are many, many developers out there that still have to compile against old frameworks and can’t update.
.NET Core makes this a great deal easier.
It would require exactly 13.62 megabytes. .NET Framework 4 updates are iterative, not cumulative. But .NET Core is fully cumulative. For each version, it requires (as of today) ~65 MB for Core Runtime, ~85 MB for Desktop Runtime, and ~20 MB for ASP.NET Runtime. SDK size wildly varies though.
Also, each version of Windows 10 updates .NET Framework 4.x. Despite this forced biannual update, I haven’t seen a single .NET app breaking.
“It would require exactly 13.62 megabytes. .NET Framework 4 updates are iterative, not cumulative”
Your original claim was that the runtime included every single version of the assemblies “down to the patch level”.
Which is very different from arguing that obviously you can do an iterative upgrade from version A to B. But you won’t retain the version A assemblies. If I download the current .NET 4.8 something I won’t find the 4.5.2 assemblies or a way to reconstruct them anywhere.
“Despite this forced biannual update, I haven’t seen a single .NET app breaking.”
Ever heard “Absence of evidence is not evidence of absence”?
You might want to check out the bug fixes in all those releases and focus on the bug fixes for features only introduced in a previous version and you have a long list of things that broke existing applications – including ones compiled for an earlier .NET Framework.
We’ve been hit by this in the past. And yes that included a .NET 4.6.1 change that broke 4.5.2 and when 4.0 legacy applications.
Dishonest word-splitting again.
Apparently, you can reason that “absence of evidence is not evidence of absence” but say weird things like ‘Your original claim was that the runtime included every single version of the assemblies “down to the patch level”.’ (It was and still is.) You want to deliberately deceive yourself to take side with a speech you’ve never heard, by a woman you’ve never seen, who is only one of the many Microsoft program managers who have said crazy things.
Suit yourself.
“Your original claim was that the runtime included every single version of the assemblies “down to the patch level”.’ (It was and still is.) ”
And that’s simply nonsense.
Go on and show me where the .NET 4.5.2 assemblies in the current 4.8 runtime download (here’s the link https://support.microsoft.com/en-us/help/4503548/microsoft-net-framework-4-8-offline-installer-for-windows ) are. Or simply execute a .NET 4.5.2 compiled app, run it under .NET 4.7 and check the file versions of various system assemblies. You’ll be very surprised.
We had .NET 4.5.2 programs broken due to an update of the .NET 4.7.0 framework in life.
I always thought that the interview question was why manhole covers are around… but manholes are probably round as it’s the strongest shape to make them in, as you’re basically boring a vertical pipe.
Actually, I have never seen a round manhole. They have all been like rooms, possibly square, but always a lot larger than the cover itself. Edit: so the point of the cover and its size is to get a man thru the cover hole, and since a persons body is more round than square, I guess that’s the reason.
The underground gallery is typically a more or less rectangular concrete box. The vertical pipe leading down to the gallery is round in cross section and made of iron or of concrete. The cover receptacle at the surface is typically round and iron. So the cover, the hatch at the top, is round to mate with the receptacle.
Why round? The traditional “official” answer is that only a round cover can’t be inadvertently dropped though the hatchway. Which demonstrates your abstract thinking math/geometry chops.
The reality may be more mundane. Manufacturing cylindrical pipe & fittings is standard plumbing practice, whether the cross section is 1/2 an inch or 36 inches or even 3 meters. Square or rectangular pipe and fittings and such? Not so much.
> The traditional “official” answer is that only a round cover can’t be inadvertently dropped though the hatchway
Oh, this was taught in primary 3 level of e-TV programme here, which talks about properties of different shapes.
Btw, you would probably be surprised to know how many adult have forgotten primary school level mathematics that they would have been taught in syllabus. Say, what is the “exact time in fraction number” when the “hour pointer” and “minute pointer” will be overlapping, or 180 degrees, or 90 degrees, between 2 adjacent “hours”.
Another prove that “you’ll lose it if you don’t use it”.
I have one fun story about the lesson on “properties of different shapes”.
When the teacher was asking us to provide characteristics about “parallelogram”, I throw out the idea that “parallelogram is a shape made with exactly 2 pairs of parallel lines”, and the teacher goes panics because this wasn’t listed on the textbook.