I agree with your individual points, but I don't think the conclusion drawn from them -- that software produced from large enough groups of people will necessarily suffer in quality because the group itself is subject to organisational/political pressures which confuse their value structures and end up manifesting themselves as poor quality products.

Any endeavour ever attempted is subject to market, fashion, and societal pressures, and I don't think Microsoft is any different than any other company which produces high quality output. It is how a company responds to these competing needs that makes the difference.

Some of these forces are even internal, for example marketing requires that the next release include feature X, even if it's incomplete or the execution is low quality. But who gave marketing the authority to make such product decisions? Suppose Microsoft were in the business of making automobiles, would marketing be allowed to require spurious features that could cause unpredictable performance problems?

In the same vein, I think it's reasonable to assume that if Microsoft were deeply concerned about only shipping excellent quality work, they would do a spectacular job of aligning the maturation curve of each feature with that of the release schedule, such that only features that are "good enough" pass the quality check and make it into a release. In such a scenario, "what marketing wants" would be lower priority than "does this pass our quality standard".

This is a matter of prioritising one set of values over another. That is to say, both of the following are true:

• There is no single reason that the managerial structure of Microsoft is required to look like what it does right now.
• There are a million and one reasons why the organisational structure of Microsoft is the way it is and isn't likely to change.

Both are true in the sense that if Microsoft's priorities were to shift in the "high quality engineering first" direction, marketing and organisational/political manoeuvres would be folded quickly into the minimal amount needed to run the organisation. On the other hand, every large body of people has significant inertia, which makes changing course more difficult than it is for smaller groups. Luckily, large organisations also have more resources than a small body of people.

So, yes, there are many reasons why the end-product ends up being the way it is, but I don't believe there is some "law of nature" like effect that necessitates that shareholders, marketing, and middle management will always exert a negative influence on the product (from the user's perspective). While the structure of the organisation may be such that this happens right now, it could be restructured so that this doesn't happen, in the same way that we can take any piece of bloated old software code and continuously refactor it until it reaches satisfactory quality. We know these things are possible, they are just very hard work which hardly anyone is willing to take on. Or in the case of Microsoft, would require buy-in from the whole organisation.

VROOM
In such a scenario, "what marketing wants" would be lower priority than "does this pass our quality standard".

Totally. We're in perfect aggreament. I'm just saying that the likelyhood of any of the positive possibilities you've just details ever materializing, in MS or anywhere, are VERY low, and "expecting" that to happen because you fill out some scenario forms and having a phone call, is just plain unrealistic.

Cudos to Casey for giving MS the benefit of the doubt, but I think he'd be much less frustrated if he had callibrated his expectations more realistically.

Just to add my personal experience:
At some prior job, when I first started the team I got into was new, and what we've inherited was the most disastreous of a pile of mud of a code base I could have ever imagined - and then some. Over the years we've made significant effort to improve the software quality VERY substantially. We had very good backing of middle-management, as we were lowering the maintenece costs by substantial amount, and increast the robustness of the solutions to a degree they had never seen before. Thanks to that, we were able to get a buy-out from some higher-management on a multi-year project of fundamental refactor/rewrite.

This is in a pretty large company which is extremely political.

Thing is, we got real lucky with some middle-management that were mostly on our side and could listen to reason.
Most other teams around the company were not nearly as lucky.
Also, our team's attitude towards software quality was very much an anomaly within the cultural landscape of the organisation. We were struggeling consistently to convey the importance of that, but it mostly just fell on deaf ears.

The consequences were that even with the massive improvements that we did, we could only improve the overall situation up to a point. Because the solution does not live in a vaccume, and needs to interface with many other solutions from many other teams. So ultimately, even in the best case, we were still handicapped by all the political and cultural landscape around us, and there was absolutely nothing we could do about it. Almost all the cases that our software broke down, was due to issues originating outside our team, and we were powerless to stop that from happening.