It feels to me that even if you accept all the arguments for why inflating an organisation's number of participants brings about inevitable decay (sort of like the Tower of Babel), and it's not the individual's fault, Casey still has a point about them (Microsoft) not caring.
Microsoft has made a few versions of its operating system that has run on whatever they have needed it: as a DOS extension, OS for IBM PCs, Media players, PDAs, and the Wikipedia page even mentions "satellite navigation systems" if you believe it.
I expect making the kernel run reliably (and perform well) is much more effort than fixing the startup time on Visual Studio or having the watch window update quickly (even though it used to do both in the VC6 days). Now, before anyone starts talking about it being impossible to turn a decayed codebase around as compared to a green-field new project like Remedy, remember that the NT kernel codebase is even older than Visual Studio, and Microsoft still finds a way to work with it. In fact, the kernel has much tighter backwards-compatibility restrictions than anything in Visual Studio ought to have, and I can't even imagine the level of politics and business decisions concerning the core OS.
So, I'd argue that Microsoft is capable of marshalling its resources to solve the problems in Visual Studio if they thought it was important (or as Casey put it -- if they cared
to do so). They don't. Whether it is because it makes no sense financially or strategically, or because they think this is okay is irrelevant from the consumer's point of view for the same reason that one wouldn't care what organisational troubles
lead to the restaurant you were eating at serving you unappetising slop. The customer cares about the results.
Also, while I agree that culture and values are king practically everywhere you have a group of people, I don't think we should use "Large groups have a hard time aligning on values, so inner conflicts seep into their work and weaken it over time" as an excuse for poor execution. It would be very easy to brush off any incompetent response from a company/government/any large body as not their fault if we take this stance to its logical conclusion which is "This is just the way things go when they get this big".
Consider if this would be a helpful attitude in more dramatic circumstances -- say a super-bridge collapsed or airplanes started falling out of the sky. I don't think people would give the builders a pass because the organisations have become so large that the political and managerial effort required to run them has outgrown the effort put into engineering. They would still be held accountable for the quality of their work.
Now, I realise that Visual Studio start-up time (and watch window stepping lag) is not a matter of life and death, so perhaps we should not hold them to the same standard, but before you resign yourself to thinking that "This is is what happens when organisations get big", think about all the times where a truly massive collection of people have organised to achieve impossible things:
- The organisational level during every war effort - I don't agree with the goal of war, but the amount of industrial organisation needed to sustain it is staggering. If you haven't read about the levels of industrial reorganisation during world war two, it's a fascinating read.
- The first Moon landing required much more engineering than whatever magic loads the modules for Visual Studio. Or even the Visual Studio installer, which hasn't been reliable for me since version 2010!
- Look at the level of organisation on any disaster response of even moderate scale. People can really get organised even without any of the infrastructure we take for granted day to day.
- Take a look at what it takes to fabricate a modern CPU. Frankly, it is crazy what you need to be able to do, crazier still if you take a look at what the supply chain looks like. This holds true for every auto and ship maker out there as well.
Large organisations can and have organised themselves to do much more difficult things than resolve code ownership issues and fix performance problems that have accrued for over a decade. It's just a matter of priority and values. This is why I think Casey can rightfully say that they don't care. The performance issues are much lower priority than, say, pushing Azure for business, so the effort ends up going there.