As a former Microsoft employee, my experience was that the longer a product was around, the harder it was to figure out who understood any part of it well enough to change something.

I would guess I averaged about 10 lines a month on my project that had been around for decades. Making even slight tweaks required dozens of meetings, design discussions, functional and performance testing, etc. etc. It took an eternity.

Microsoft is still actively patching Skype. Here's an example of them patching what sounds like a similar DLL flaw just last year:

https://www.cvedetails.com/cve/CVE-2017-6517/

And don't forget that the product work as expected in most cases and many changes are not justified.

The bike shed won't get painted to a new color just because a the new middle manager asked for it.

Ironically I would comment exactly what you did with, but the roles reversed:

“If this was a small startup I couldn’t see those being hurdles but at a behemoth like MS with an almost 2 decade old product I can.”

I feel like you've got those reversed. In small startup the bug fix would be deployed to production before it's committed to source control.

In a large enterprise the process isn't too hard, it's just complicated.

I was neither justifying or admonishing MS for this issue, I was just responding to a gross trivialization of the process that I found offensive.

> 24 - 72 hours for a fairly critical and relatively easily solved security bug

Let's see. How many microsoft employees would it take to change a lightbulb? ;-)

https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-...

Highlight:

> That initial five minutes of dev time translates into many person-weeks of work and enormous costs

This is just to add an interesting article on top of the sibling comment from the MS employee; nothing's easy in the engineering of a large product.

I'm guessing if they fix this bug the simple way they break the entire product and the proper way is many months of work (entire eco-system restructure).