I have you an analogy with a car. You earned the money to buy it and, when someone misrepresented its abilities to you, you should be upset with that seller. It is an altogether different thing to acquire out of ignorance an opinion that a better car was possible and was not given to you. If the premise is correct, one has the right to be angry with the manufacturer. But one has to make sure that it is, and most of those "angry" with MS do not. As I said earlier, most express the lack of basic knowledge and act, simply, like spoiled, self-centered brats that are offended at the mommy for buying them a less than perfect toy.
Can some one rightfully claim that the manufacturer is at fault, that the quality of the car is indeed unjustifiably poor? Of course. The key is "unjustifiably:" one has to (i) know enough about the state of the art, and (ii) then claim that the manufacturer has not delivered on feasible state of the art. One lacks such sophistication if one merely drives the car. This is were my references to compiler construction come from: most programmers, as I said, know nothing of computer science, much like most who drive cars know nothing of elementary physics and engineering. And, in order to ascertain that MS did not deliver one has to be a computer engineer and/or business manager. My original remarks were exactly that: anyone who studies software engineering would know about the impossibility of debugging a code of any reasonable size.
People do with MS what they do with their own managers: just by observing their bosses they conclude they know management. They can b--ch ad infinitum about all the shortfalls: they (the management) should have done this or that; "it was clear to me from the start that this was doomed to failure, but our stupid managers didn't even know..."
Well, lighting the cooking gas in the kitchen does not make you a chemical engineer: you want form engineering opinions, study engineering. Similarly here: you want know about product development and pricing, study marketing (which most people confuse with either advertising or sales). After just one course people like Charlotte on this thread would not make silly claims about too heavy user interfaces of Windows: the question is, who is the user? The composition and distribution of Windows is not a programming issue -- it is a managerial one. And, the reason corporations buy Windows is not how it is programmed either. Again, a reasonable introductory course in management would show that very quickly.
That is about it. To give you a courtesy of reply to specific points:
if someone doesn't know how to write a compiler (I couldn't), he cannot evaluate an operating system. HE can evaluate whether that system suits his needs. He is unable, indeed, to judge whether a better one could be produced. One needs education for that.
But, deadlock avoidance is not writing a compiler, either. So where on the spectrum do you believe one does become qualified to criticize? I was not making a list of necessities: I was giving examples of what one acquires from education rather than practice. One does not learn deadlock avoidance/preventions, re-etrance of code, compiler construction, balanced binary trees, and memory clean up by writing software for clients: the time for that has passed long ago. If one does know these things, he or she has acquired them by education (after which one could also write such programs at MS or Oracle).
Of the products out there, what possible reason for a real, large, complicated application would one choose that product? There are five or six features that (i) are common to professional buying and (ii) differentiate it from non-professional consumer buying. Here, too, people routinely project their own, consumer experience onto corporate and other organizations. Consult a marketing text for details.
Is it market exigencies? Surely to a degree. This goes back to corporate buying, which is the main market for MS.
Only that could explain the release of Word97 with 7,500 known bugs. I do what I preach: not knowing the managerial details of that project, I do not even have an opinion on the matter. It is quite likely, given the experience with other products, that this was indeed a blunder. But, again, I do not know: all I could see the programming mistakes; I did not and do not know what timing constraints the project managers had at the time.
But I have to also reject the syllogism that since MS has great programmers, the products are all great. Again, it is you who speaks of programmers: I spoke of talent in general. What makes MS great is not so much the programming talent but the fact that they managed to combine it with great managerial talent as well. This is where I am pushing your thinking: even subconsciously, you view everything from the standpoint of programming. Yet most of the issues you raised are not: they have to do with management and organizational behavior.
Therefore, where IS the problem? Which problem?
I do not think they have a problem. It is the consumers that grew to take MS products for granted that have a problem. It is our country that has raised a couple of generations of whining, self-centered brats that had it good for a long, long time --- that is who may have a problem. MS is doing fine, the last time I checked on it.
MS will grow or die on the judgment of millions who CANNOT write the complier or know anything about deadlocks. Look, you can stop patronizing a particular restaurant, and it will go bankrupt, I agree. It is your money, and you can say that you were displeased with the quality of food or ambiance. As you are causing the demise of that restaurant, you should not make judgments the restaurant' managers, unless you know both management in general and the specific circumstance in particular. To put it simply, as you leave the restaurant, say that you did not like it and that it did not suit your needs; but unless you have reasonable expertise in this area, do not say that the restaurant itself did not make any sense as a product/venture.
I have tried to show you, respectfully, that you and I impute different meanings to the words here. Most of the words and opinions you raise have managerial aspects to them. I have no reason to disrespect your programming or business acumen, but if you want to claim managerial blunders on the part of MS, then please speak from that standpoint.
I enjoyed our conversation, but will not bee able to contribute to it more than I already did. Thanks for writing,
TQ.
There's so many of these MS issues -- over 50 this year alone -- that there's no point in posting a new thread on each one.
So I'm just adding them here, for anyone interested:
To prove that no security bug is truly harmless, a security group has stitched together two minor flaws in Microsoft's Internet Explorer 6.0 browser with a small glitch in Windows Media Player to create one seriously powerful attack.
By coaxing IE users to view a Web page containing the special code, an attacker can silently force Windows 98, Windows 2000, or Windows XP users to run a malicious program of the attacker's choice.
Using a rarely used feature called 'message fragmentation and re-assembly' (MFR), an attacker can send emails that will "bypass most SMTP filtering engines", Beyond Security reports.
This MFR feature, which allows Internet users to split up sent messages, helping surfers with slow connections to send smaller segments of a larger email in multiple emails, is supported by Internet standards (RFC 2046) but easily enabled on only one client - Outlook Express.
On Outlook Express the re-assembly feature is enabled by default, while the fragmentation feature can be enabled from a drop down menu.
This is a horribly nasty and childishly easy exploit and Microsoft can't patch it a moment too soon. The fact that the feature exists at all is ample illustration that Microsoft places usability (users don't want to click on dialogue boxes) over security.